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: accept tags of the form X.Y.Z (without leading 'v') as semantic versions #32945

Closed
tamalsaha opened this issue Jul 4, 2019 · 51 comments
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone

Comments

@tamalsaha
Copy link

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

$ go1.13beta1 version
go version go1.13beta1 linux/amd64
$ go version
go version go1.12.6 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/tamal/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/tamal/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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 -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build803673677=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ go1.13beta1 get github.com/kubedb/[email protected]
go: finding github.com/kubedb/apimachinery v0.11.0
go: finding github.com/kubedb/apimachinery v0.11.0
go: finding github.com v0.11.0
go: finding github.com/kubedb v0.11.0
go get github.com/kubedb/[email protected]: unknown revision v0.11.0

$ go1.13beta1 get github.com/kubedb/[email protected]
go: finding github.com/kubedb/apimachinery 0.11.0

We use the git tag also as the Docker image tag. I like kubedb/operator:1.0.0 (without v) over kubedb/operator:v1.0.0. So, we went with that. Tools like glide, dep will automatically handle the presence or absence of v. But go mod does not do that.

What did you expect to see?

My question is can go mod automatically search for both of these prefixes?

What did you see instead?

@dmitshur dmitshur added modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. labels Jul 4, 2019
@dmitshur dmitshur added this to the Go1.14 milestone Jul 4, 2019
@dmitshur dmitshur changed the title Automatically handle vX.Y.Z and X.Y.Z cmd/go: automatically handle vX.Y.Z and X.Y.Z Jul 4, 2019
@bcmills bcmills changed the title cmd/go: automatically handle vX.Y.Z and X.Y.Z cmd/go: accept tags of the form X.Y.Z (without leading 'v') as semantic versions Jul 18, 2019
@bcmills
Copy link
Contributor

bcmills commented Jul 18, 2019

See previously #30146.

@bcmills
Copy link
Contributor

bcmills commented Jul 18, 2019

CC @jayconrod

To reiterate from that discussion: the difference is mainly aesthetic and relatively arbitrary. Absent a compelling need otherwise, Go usually resolves aesthetic differences by picking one to use consistently (think of gofmt), not supporting both.

@jayconrod
Copy link
Contributor

+1 to not supporting this. It's unfortunate that different systems have different standards for this, but supporting both formats would lead to ambiguity and confusion. For example, both vX.Y.Z and X.Y.Z might exist and point to different commits.

go release should probably warn against creating such a version accidentally in the future.

@bcmills
Copy link
Contributor

bcmills commented Jul 18, 2019

supporting both formats would lead to ambiguity and confusion

Note that there is a similar problem for build metadata, which we resolve (in Go 1.13) by resolving to a unique pseudo-version derived from the tagged version.

@mattharr-is
Copy link

i think the ironic part about all of this is this bit in the semver.org FAQ
https://semver.org/#is-v123-a-semantic-version
In my case, we have an existing build system that handles repo versioning and tagging for us, using standard semver format (no v prefix). When one reads the go module docs about how it all works with a "standard semver format", and then seeing that it's not actually standard semver format, is a bit confusing. It also requires retooling some build processes that actually do follow the standard.

@alexellis
Copy link

+1 cc @LucasRoesler @Waterdrips @stefanprodan - we were all hit by this today, we use semver but "the valid way" i.e. without a "v" prefix and dep was fine for us - we could have a proper tag in our dependency file, but now we're stuck with lots of v0.0.0 SHA in all our code. Was hoping that moving to go modules was going to be a pleasant, pain-free upgrade.

We don't want to change the tags if we can avoid it because semver itself recommends against no prefix and also, we rely on the numbering for Docker images.

wadells added a commit to wadells/robotest that referenced this issue May 13, 2020
As discussed at:

  golang/go#32945
  https://semver.org/#is-v123-a-semantic-version

Go and semver disagree about handling of a leading 'v' on version
strings.  This patch allows robotest to play nicely with both.
wadells added a commit to wadells/robotest that referenced this issue May 13, 2020
As discussed at:

  golang/go#32945
  https://semver.org/#is-v123-a-semantic-version

Go and semver disagree about handling of a leading 'v' on version
strings.  This patch allows robotest to play nicely with both.
wadells added a commit to wadells/robotest that referenced this issue May 13, 2020
As discussed at:

  golang/go#32945
  https://semver.org/#is-v123-a-semantic-version

Go and semver disagree about handling of a leading 'v' on version
strings.  This patch allows robotest to play nicely with both.

Contributes to gravitational#200.
wadells added a commit to gravitational/robotest that referenced this issue May 14, 2020
As discussed at:

  golang/go#32945
  https://semver.org/#is-v123-a-semantic-version

Go and semver disagree about handling of a leading 'v' on version
strings.  This patch allows robotest to play nicely with both.

Contributes to #200.
@gudvinr
Copy link

gudvinr commented Jul 9, 2020

We consistently use unprefixed tags X.Y.Z versions across all of the internal projects. Some of them are shared between projects and not every project is written in Go. This is really annoying requirement because it is not language-related but still ruining existing workflow.

Arguments like "you may have both prefixed and unprefixed tags in repo" is quite silly because if you do have such tags in your repo you probably have a bigger problem with your VCS already.

You may as well have very old commit tagged by higher version number and this also doesn't look right. You may have tags with same version and different metadata which is not used in version comparison too.

@gudvinr
Copy link

gudvinr commented Jul 9, 2020

the difference is mainly aesthetic and relatively arbitrary.

@bcmills This is not aesthetic for projects that existed outside of Google (and companies that use prefixed tags) before introduction of go modules. It is messing up with build process.

Reference to gofmt also seems wrong here. gofmt is tool for Go language only and can't interfere with anything outside Go ecosystem, but requirement on git tags leads to unwanted changes.

@taiidani
Copy link

Agreeing with the above. My company is highly polyglot among multiple languages but our release and tagging automation is reused between them. We implemented this logic using the "correct" semver way without the "v" prefix.

It will be an extremely bitter pill to swallow if we have to update our automation and [ideally] re-tag all of our repositories to add the "v" prefix because of one languages' requirement.

@MCBrandenburg
Copy link
Contributor

I'm in the a similar boat to @taiidani, trying to get a company to prefix with their already automated process with a v to satisfy the case for go FusionAuth/go-client#32

gotgenes added a commit to gotgenes/getignore that referenced this issue Aug 28, 2020
This is to support using go mod, and is necessary until
golang/go#32945 is resolved.
@mieubrisse
Copy link

Another +1 - we started our project using X.Y.Z the official semver way, but consumers of our library are confused as to why the go.mod file ends up as v0.0.0-YYYYMMDDSSSSS-abcd1234

@FiloSottile
Copy link
Contributor

This does not feel worth introducing conflicts and confusion about which of two tags v1.2.3 and 1.2.3 is the correct one. Moreover, we definitely should not magically promote to versions existing unprefixed tags without any action on the repository's part, which would require yet another complexity axis (like the go.mod version).

About unprefixed tags being the "official" way, I don't think that's what the docs say. The semver FAQ explicitly calls out using v as a prefix for git version tags (not all git tags are versions), and this is the GitHub help sidebar in the release page.

image

@gudvinr
Copy link

gudvinr commented Feb 21, 2021

A setting would have much of the same performance and complexity cost as gating on the go.mod version, as described above.

What about performance and complexity cost added by checking for existence of go.mod for prefixed tags in projects existed before go.mod?

@FiloSottile
Copy link
Contributor

The existence and contents of go.mod do not influence the choice of what tags represent a version, as far as I know, while the mechanisms proposed here would.

Anyway, the whole +incompatible migration was definitely complex and confusing. That was necessary to make modules happen at all. I don't think supporting multiple tagging conventions is worth nearly as much disruption.

I understand that there are projects that have strong opinions on the tagging scheme and that are inconvenienced by the scheme we picked, but I also notice that it looks like this is not a particularly common issue: the proposal currently has 23 👍, which puts it in page 8 of is:issue is:open sort:reactions-+1-desc. This is not a primary concern in deciding what to implement—they are not votes—but it's an indicator of how relatively widespread the issue is, which we need to keep in mind when considering changes that might affect all Go developers, directly or indirectly.

@mieubrisse
Copy link

Thanks for explaining the underlying machinery that would need to be implemented, @FiloSottile ! Tactically, how should we go about handling repos where the vX.Y.Z requirement conflicts? E.g. I have a repo that has both Go and Rust subprojects, where Go is requiring vX.Y.Z while Rust requires X.Y.Z.

@gudvinr
Copy link

gudvinr commented Feb 21, 2021

The existence and contents of go.mod do not influence the choice of what tags represent a version, as far as I know

Existence of go.mod does though. Correct me if I'm wrong but there's couple of comments there:

// The latest compatible version has a go.mod file, so assume that all
// subsequent versions do as well, and do not include any +incompatible
// versions.
// The latest release of this major version has a go.mod file, so it is
// not allowed as +incompatible. <...> so drop all +incompatible
// versions for this major version.

it looks like this is not a particularly common issue

Opinions based on github user base will be kinda biased. As Dave and you mentioned before, many projects already had prefixed versions but from what I understand this research was based mostly on github projects. And github slightly pushes you towards having prefix in version tag despite it being optional in every spec available.

Time also has a huge impact on this issue. Issue that Dave linked here is from 2015 but this one is quite recent. Go itself somewhat skyrocketed in 2016-ish. If you're just starting project, using any tag scheme is painless even mandatory one. It is relatively easy to change if you only use Go.
It is completely different story if you use different languages and if you have some kind of CI it may be inconvenient. Either at the same time or while switching from another language to Go. Projects impacted by this issue may be internal so pseudo-versions are good enough™ but that still cause inconvenience although it's impossible to know how much.

@bcmills
Copy link
Contributor

bcmills commented Feb 22, 2021

@mieubrisse

Tactically, how should we go about handling repos where the vX.Y.Z requirement conflicts? E.g. I have a repo that has both Go and Rust subprojects, where Go is requiring vX.Y.Z while Rust requires X.Y.Z.

Is there something preventing you from adding both forms of tags?

@gudvinr
Copy link

gudvinr commented Feb 22, 2021

Is there something preventing you from adding both forms of tags?

It is kinda confusing, I'd say.
What are you going to do if you put v3.4.5 and 3.5.4 on a single commit by accident?
What are you going to do when you forget to add one of them?
How do you explain team members who do not use go or rust that they must place both tags from now?

Last one may not be applicable for this particular team, but adding responsibilities for people who don't even use go is not really a viable solution.

@criscola
Copy link

I think that we should support versions without v prefixes because Semver is an open, industry-wide standard. In this occasions I think we should always strive to support the open standard. Then we can say we support versions with a v prefix because there is a significant amount of people who use this convention.

At the very least I would expect to have one line of docs explicitly stating versions must be prefixed with v in the About page, and maybe avoid linking the semver website to avoid confusion.

@joe-mann
Copy link

I think that we should support versions without v prefixes because Semver is an open, industry-wide standard. In this occasions I think we should always strive to support the open standard.

But semantic versioning doesn't say anything about the v prefix. This is a Go convention.

And as I have understood FiloSottile's comments (notably #32945 (comment)), there are significant hurdles to overcome to loosen this convention. I surmise that, if this issue had been opened during the planning and development of modules, Go may well have supported both tagging schemes from the start.

Then we can say we support versions with a v prefix because there is a significant amount of people who use this convention.

Yes, but as explained in #32945 (comment), there do not appear to be anything like a significant number of people who experience significant issues interoperating with Go.

At the very least I would expect to have one line of docs explicitly stating versions must be prefixed with v in the About page, and maybe avoid linking the semver website to avoid confusion.

By way of reference, the tagging standard is explained here: https://golang.org/doc/modules/release-workflow. Personally, I don't think we're lacking clarity in this regard.

@wallyqs

This comment has been minimized.

@seankhliao

This comment has been minimized.

@wallyqs

This comment has been minimized.

@seankhliao

This comment has been minimized.

@wallyqs

This comment has been minimized.

@rsc
Copy link
Contributor

rsc commented Feb 2, 2022

As has been discussed, we chose the v specifically to avoid problems with legacy repos that had old tags.
Now we wouldn't want to change that, nor would we want the possibility of two different conflicting tags for a given version.

@rsc
Copy link
Contributor

rsc commented Feb 2, 2022

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

@rsc
Copy link
Contributor

rsc commented Feb 9, 2022

No change in consensus, so declined.
— rsc for the proposal review group

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests