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

Comments

@iiinsomnia
Copy link

@iiinsomnia 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

This comment has been minimized.

Copy link
Member

@andybons 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 this to the Unplanned milestone May 8, 2019
@thepudds

This comment has been minimized.

Copy link

@thepudds 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

This comment has been minimized.

Copy link
Author

@iiinsomnia iiinsomnia commented May 9, 2019

go 1.12.4 @andybons

@iiinsomnia

This comment has been minimized.

Copy link
Author

@iiinsomnia iiinsomnia commented May 9, 2019

@thepudds sorry, mistake in writing.

go get A@v0.0.1

@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented May 9, 2019

@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

This comment has been minimized.

Copy link
Author

@iiinsomnia iiinsomnia commented May 10, 2019

  • 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

This comment has been minimized.

Copy link
Member

@bcmills 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 May 10, 2019
@iiinsomnia

This comment has been minimized.

Copy link
Author

@iiinsomnia iiinsomnia commented May 13, 2019

thanks a lot !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.