Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"go get" not working for v2.0.0 #138

Open
qjcg opened this issue Sep 24, 2020 · 3 comments
Open

"go get" not working for v2.0.0 #138

qjcg opened this issue Sep 24, 2020 · 3 comments
Assignees

Comments

@qjcg
Copy link

qjcg commented Sep 24, 2020

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

$ go get github.com/sourcegraph/checkup@v2.0.0
go get github.com/sourcegraph/checkup@v2.0.0: github.com/sourcegraph/checkup@v2.0.0: 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:

@titpetric
Copy link
Contributor

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
Copy link
Author

qjcg commented Sep 24, 2020

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

go module using major branches

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 titpetric self-assigned this Sep 29, 2020
@titpetric
Copy link
Contributor

titpetric commented Sep 29, 2020

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 ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants