"go get" not working for v2.0.0

[qjcg]

checkup v2.0.0 was released on April 29th, 2020, but it's not installable via go get:

$ go get github.com/sourcegraph/[email protected]
go get github.com/sourcegraph/[email protected]: github.com/sourcegraph/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

And when a simple go get github.com/sourcegraph/checkup is run with no version query, v1.0.0 is installed, despite it not being the most recent release.

The reason is that Go modules are being used, and once a module hits major version 2 or beyond, a major version suffix is required.

A major version suffix can be added to this repo by creating a v2 directory for v2 code (for a full worked example, see the "Publishing v2 and beyond" section of the "v2 and Beyond" article below).

For further detail, please see:

• Go Modules Reference: Major Version Suffixes
• Go Modules: v2 and Beyond

[titpetric]

I'm getting conflicting information here, can this be resolved by using a v2 branch or not? I'd rather untag the v2 tag and from what's written in version queries, a branch could be selected. Having a v2/ subfolder isn't desired.

A revision identifier for the underlying source repository, such as a commit hash prefix, revision tag, or branch name. If the revision is tagged with a semantic version, this query selects that version. Otherwise, this query selects a pseudo-version for the underlying commit. Note that branches and tags with names matched by other version queries cannot be selected this way. For example, the query v2 selects the latest version starting with v2, not the branch named v2.

Can you use @master (the tagged version is a bit out of date as well). If we had a codename for the v2 release, which wouldn't be called v2, but lets say quantum, then using @quantum would also work, right?

[qjcg]

You can absolutely use a v2 branch instead of a subfolder. See for example the "go module using major branches" diagram here:

In the v2 branch, you'd need to:

• Append v2 to the module path ingo.mod: github.com/sourcegraph/checkup/v2
• Update any imports in the v2 branch accordingly. So for example import "github.com/sourcegraph/checkup/types" would become import "github.com/sourcegraph/checkup/v2/types"

Apparently marwan-at-work/mod will do the above for you automatically with one command (but I haven't used it myself).

To answer your questions about version queries: yes, any git ref including @master and @quantum (as a tag, branch, etc) will work. The reason that @v2.0.0 does NOT work is that it resolves to a semantic version, and according to the Module paths doc here:

If the module is released at major version 2 or higher, the module path must end with a major version suffix like /v2 [emphasis added]

[titpetric]

Thanks for the clear explanation. I assigned it to myself and will set up a v2 branch as soon as possible, until then please resort to the @master branch ;)