这与 #33010 问题基本相同。
不幸的是，这种行为无论如何都会让人感到有些困惑：如果一个仓库有一个标签 v0.14 和一个标签 v0.14.1 ,而你运行 go get […]@v0.14 ,你应该得到该前缀的最高补丁版本( v0.14.1 )还是具有精确匹配文本的标签( v0.14 )?答案似乎并不明显。
总的来说，这应该只是一个过渡性问题：我们期望，向前发展，为 go 命令标记版本的人将使用完整的语义版本进行标记。
CC @jayconrod

我认为这是一个更大的问题，对于分支来说。我认为人们很可能会命名主要或次要的发布分支，如v2或v2.3。
我想知道我们是否应该实际上放弃这些名称的查询功能？我的印象是大多数人不知道或者不使用它。获取其中一个分支的最新信息的能力对我来说似乎更有用。

我支持放弃基于前缀的查询，转而支持分支名称。不过，也许可以将其作为一个单独的提案提交？

FWIW,我同意@jayconrod的#29731(评论)将查询前缀改为更好地支持分支名称。我认为这是一个净收益，并且更好地符合人们对常见情况下发生的事情的直觉。
两个相关的评论：

1. 对于一个模块，能够使用@v2作为前缀并不是那么有用，因为你需要在模块路径的末尾有/v2。
2. 你目前也可以使用go get 'foo@>=v1.3',这与使用v1.3作为前缀几乎具有相同的功能。(我怀疑大约相同数量的gophers知道这两个中的每一个，也就是说，可能大多数gophers目前都不知道其中一个)。它们的功能并不完全相同，包括在这个例子中，如果有一个角落情况存在v1.4.0版本但没有v1.3.x版本(尽管我认为这个特定的角落情况可能是违反了semver规范)。在实践中，它们可能足够接近以解决类似的用例，从而减轻使用前缀的损失。

同意。我认为我们将尝试将其切换到1.14版本。

这并没有达到1.14版本。我们或许可以在1.15版本中再次尝试。

在go1.17中，go get已被弃用，将打印出明确的错误信息。

$ 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'.

缺少补丁号触发了一条关于格式的消息，但没有提到补丁级别，这似乎是合适的：

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

问题似乎已经解决。

这仍然在模块内重现：

$ 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"