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

cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag or branch #29731

lopezator opened this issue Jan 14, 2019 · 6 comments


Copy link

@lopezator lopezator commented Jan 14, 2019

What version of Go are you using (go version)?

$ go version
go version go1.11.4 darwin/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6n/q8wt03m13_x3w6v5__mzkwgc0000gn/T/go-build342969942=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go get

What did you expect to see?

The package apns2 added sucessfully to the go.mod file and downloaded to pkg/mod using pseudo-version or whatever although it doesn't have a valid semver tag (patch number missing).

What did you see instead?

This cryptic error (it took me several minutes to realize that a patch version was missing)

go get no matching versions for query "v0.14"


The only workaround I found is to pin to the latest commit SHA inside the v0.14 tag on the required repository.

CC\ @bcmills

@bcmills bcmills added this to the Go1.13 milestone Jan 14, 2019
@bcmills bcmills changed the title cmd/go: go get with invalid semver tags doesn't work and gives poor debug info cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag Jan 14, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
Copy link

@bcmills bcmills commented Jul 18, 2019

This is more-or-less the same underlying issue as #33010.

Unfortunately, the behavior is necessarily going to be a bit confusing one way or the other: if a repository has a tag v0.14 and a tag v0.14.1, and you run go get […]@v0.14, should you get the highest patch version for that prefix (v0.14.1), or the tag with exact matching text (v0.14)? The answer doesn't seem at all obvious.

In general this should only be a transitional problem anyway: we expect that, going forward, folks who tag versions for use with the go command will tag using complete semantic versions.

CC @jayconrod

@bcmills bcmills modified the milestones: Go1.14, Unplanned Jul 18, 2019
Copy link

@jayconrod jayconrod commented Jul 18, 2019

I think this is a bigger problems for branches. I think it will be very common for people to name major or minor release branches like v2 or v2.3.

I wonder if we should actually drop the query functionality for these names? I get the impression that most people don't know about it or don't use it. The ability to get the tip of one of these branches seems more useful to me.

Copy link

@bcmills bcmills commented Jul 18, 2019

I would be ok with dropping query-by-prefix in favor of supporting branch names. Maybe file that as a separate proposal, though?

@bcmills bcmills changed the title cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag cmd/go: 'go get' with semantic-version prefix doesn't fall back to matching tag or branch Aug 7, 2019
Copy link

@thepudds thepudds commented Aug 27, 2019

FWIW, I agree with @jayconrod's #29731 (comment) to drop query-by-prefix to better support branch names. I think that would be a net win, and better align with people's intuitions about what happens in common cases.

Two related comments:

  1. For a module, being able to use @v2 as a prefix is not that useful, given you need to have the /v2 at the end of the module path.

  2. You can also currently do go get 'foo@>=v1.3', which is almost the same functionality as using v1.3 as a prefix. (I suspect roughly the same number of gophers know about each of those, which is to say that probably most gophers do not know about either one currently). They are not identical functionality, including in that example if there is a corner case where a v1.4.0 exists but no v1.3.x exist (although that particular corner case I think might be a violation of semver spec)... In practice, they might be close enough to addressing similar use cases that it mitigates the loss of using a prefix.

Copy link

@bcmills bcmills commented Aug 27, 2019

Agreed. I think we're going to try switching it over for 1.14.

Copy link

@bcmills bcmills commented Jan 6, 2020

This didn't make 1.14. We can perhaps try again in 1.15.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.