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

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.

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

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.

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

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

Following the deprecation of go get with go1.17, an explicit error message prints.

$ gotip version
go version devel go1.22-1e69040920 Fri Sep 29 22:29:16 2023 +0000 windows/amd64

$ gotip get github.com/sideshow/apns2@v0.14
go: go.mod file not found in current directory or any parent directory.
        'go get' is no longer supported outside a module.
        To build and install a command, use 'go install' with a version,
        like 'go install example.com/cmd@latest'
        For more information, see https://golang.org/doc/go-get-install-deprecation
        or run 'go help get' or 'go help install'.

The absence of patch number triggers a message about format without mentioning the patch level which seems appropriate:

$ gotip install github.com/sideshow/apns2@v0.14
go: github.com/sideshow/apns2@v0.14: no matching versions for query "v0.14"

Issue seems solved.

This still reproduces within a module:

$ go version
go version devel go1.22-8c3924c6 Fri Sep 29 09:00:12 2023 +0000 linux/amd64

$ go mod init example
go: creating new go.mod: module example

$ go get github.com/sideshow/apns2@v0.14
go: github.com/sideshow/apns2@v0.14: no matching versions for query "v0.14"