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: change tag can not get the new commit version #31903

Closed
iiinsomnia opened this issue May 8, 2019 · 8 comments
Closed

cmd/go: change tag can not get the new commit version #31903

iiinsomnia opened this issue May 8, 2019 · 8 comments
Labels
FrozenDueToAge modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@iiinsomnia
Copy link

iiinsomnia commented May 8, 2019

now, there is a go module A.

step1: add new tag v1.0.1 to commit_1
step2: delete the tag v1.0.1
step3: modify and commit as commit_2
step4: add the tag v1.0.1 to commit_2

when I run go get A@v1.0.1, it gets the version of commit_1 instead of commit_2 and in the go.mod shows A v0.0.0-20190507092345-afa2bget21xc instead of A v1.0.1

@andybons
Copy link
Member

andybons commented May 8, 2019

@iiinsomnia what version of Go are you using? What's your environment? In other words, please use the new issue template.

@bcmills @jayconrod

@andybons andybons added modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels May 8, 2019
@andybons andybons added this to the Unplanned milestone May 8, 2019
@thepudds
Copy link
Contributor

thepudds commented May 8, 2019

@iiinsomnia FWIW, Go modules require that modules follow the semver spec, and as far as I am aware, it is not allowed under the semver spec to move a tag from commit_1 to commit_2 as in your example if that initial tagging represents an actual release viewable by others.

For example, from https://semver.org/#spec-item-3:

  1. Once a versioned package has been released, the contents of that version MUST NOT be modified. Any modifications MUST be released as a new version.

That said, in your case, you might want to try doing go clean -modcache. That might help, but not sure.

Also, the top-half of your example is using v1 major version tags, but then the last part of your example says:

go get A@v0.0.1

Is that intentional that you switched to a v0 major version tag there?

@iiinsomnia
Copy link
Author

go 1.12.4 @andybons

@iiinsomnia
Copy link
Author

@thepudds sorry, mistake in writing.

go get A@v0.0.1

@jayconrod
Copy link
Contributor

@iiinsomnia Could you post a small example repository with tags that demonstrates this problem? A sequence of commands would be helpful. And we still need the output of go env.

@iiinsomnia
Copy link
Author

  • go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/shenghui/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/workspace/go"
GOPROXY="https://goproxy.io"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j5/v0z7l6f53rs6lc9g2nyd37800000gn/T/go-build753395015=/tmp/go-build -gno-record-gcc-switches -fno-common"
  • repository
github.com/iiinsomnia/yiigo@v3.1.2

@bcmills
Copy link
Contributor

bcmills commented May 10, 2019

I think @thepudds has the right diagnosis.

@iiinsomnia, the mapping of commits to versions must not be changed once a version is published. That is a core property of Go modules: it is what makes builds reproducible and enables proxies and caching.

If there is a serious problem with v1.0.1, it's ok to remove the tag (so that new direct fetches will not be able to use that version), but the fix must be tagged v1.0.2, not v1.0.1 again.

(Note that we do not currently have a mechanism to inform proxies that an existing version is no longer safe to use; that's #24031.)

@bcmills bcmills closed this as completed May 10, 2019
@iiinsomnia
Copy link
Author

thanks a lot !

@golang golang locked and limited conversation to collaborators May 12, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

6 participants