-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
Comments
See previously #30146. |
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 |
+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
|
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. |
i think the ironic part about all of this is this bit in the semver.org FAQ |
+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 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. |
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.
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.
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.
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.
We consistently use unprefixed tags 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. |
@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 |
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. |
I'm in the a similar boat to @taiidani, trying to get a company to prefix with their already automated process with a |
This is to support using go mod, and is necessary until golang/go#32945 is resolved.
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 |
This does not feel worth introducing conflicts and confusion about which of two tags About unprefixed tags being the "official" way, I don't think that's what the docs say. The semver FAQ explicitly calls out using |
What about performance and complexity cost added by checking for existence of |
The existence and contents of Anyway, the whole 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 |
Thanks for explaining the underlying machinery that would need to be implemented, @FiloSottile ! Tactically, how should we go about handling repos where the |
Existence of
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. |
Is there something preventing you from adding both forms of tags? |
It is kinda confusing, I'd say. 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. |
I think that we should support versions without At the very least I would expect to have one line of docs explicitly stating versions must be prefixed with |
But semantic versioning doesn't say anything about the 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.
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.
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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
As has been discussed, we chose the v specifically to avoid problems with legacy repos that had old tags. |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
We use the git tag also as the Docker image tag. I like
kubedb/operator:1.0.0
(without v) overkubedb/operator:v1.0.0
. So, we went with that. Tools likeglide
,dep
will automatically handle the presence or absence ofv
. Butgo 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?
The text was updated successfully, but these errors were encountered: