build: use a zero for third digit for major release, such as 'go1.21.0' #57631
Comments
|
I continue having to explain around the confusion of the missing trailing dot-zero. Especially when users report bugs on my projects written in Go, as they say "I'm on Go 1.X", and that is very ambiguous - especially given that many new users see In other words, some people understand
Perhaps unsurprisingly, I wouldn't support this alternative :) I want to make the release versions explicit. |
|
CC @golang/release |
|
This may be an idea whose time has come. I'll reserve feedback for later to let more people weigh in. I just wanted to reply to this:
This error only happens for the work module's go.mod. In dependency go.mod files, the parser runs in 'lax' mode, where it is more forgiving of things it doesn't understand. For the |
|
Hi @rsc 👋
Ah, I didn't check that. That might close off this avenue for helping with broader enforcement for things like #56010.... though maybe there is some other potential modification... but that's perhaps unlikely, and probably even less likely to be as natural as just using three digits in the existing go line. As an example of another possibility, this seems to fail even in lax parsing mode for a dependency: ... but that stutter is a bit ugly. (Playground link, in case anyone wants to try variations). I suppose cmd/go could take on doing some transformation to a breaking format when something like
As a side note, I'd vote for a K > 1. There's a decently long tail of people out there that don't quite move at the pace of the Go project's officially supported versions... |
|
And of course, when it comes to K, it could be worth cheating time a bit by adding some tiny bit of knowledge in a patch release, similar to how go1.11 was the first Go version of modules, but go1.9.7 and go1.10.3 picked up a tiny bit of knowledge to help with the transition. Picking sample numbers, something like:
Alternatively, instead of the first bullet there picking a specific version to consider a hard error, a patch release could roll back the three-digit lax parsing in dependencies, or something along those lines. Given this would be done now with foreknowledge, it could be a friendlier error. Finally, it looks like the lax parser also rejects a go directive more more than two terms, which means something like |
|
I think we can leave intentionally breaking old toolchains to #57001. Writing 'go 1.21.0' would work today in the past many Go versions. So this issue can just be about "should we call the next release Go 1.21.0" instead of "Go 1.21"? Probably we should call it "Go 1.21.0" so that when people say "Go 1.21" it is clear they mean the overall sequence of point releases and not specifically the first one. For example in Docker golang you can ask for go1.21.1 but as I understand it you can't ask for go1.20. Saying "FROM golang:1.20" gets you the latest 1.20 point release. Is there anything that would break if we call the next major release Go 1.21.0? We know version strings can handle 'go1.21.0' because they handle 'go1.21.1'. |
At least some code that parses Go versions and/or tags may have special cases to account for ".0" currently being left out, and that would need to change (for example, see here) to treat go1.21.0 the same as go1.21. Code that constructs Go download URLs by relying on the current pattern (e.g. I don't see discussion of what, if anything, should happen to pre-release versions like RC 1 above. More changes may be needed to handle pre-release versions depending on the answer to that. |
|
This proposal has been added to the active column of the proposals project |
|
Hi @dmitshur
Personally, I think the pre-release versions could be left alone and there could be |
|
The standard format for a semver prerelease would be something like That and everyone who has an existing semver library they could use (e.g. actions/setup-go and so on) will be in a better place, and probably Go itself if it wants to be distributed via the module proxy, which would too expect valid semver. |
Agreed. Better to rip off the band aid and align everything under one naming scheme. |
|
It's already not semver because there is a "go" prefix. We're going to keep that. We also don't have prereleases of point releases - there is no go1.21.1rc2 today. We're not going to move to semver, so we don't need to be "more" like semver. Let's keep this proposal focused on adding the .0 only. Thanks. |
|
@dmitshur, re
I don't understand this. If we change the version to go1.21.0 won't we also change the file name to say 1.21.0, which would make this pattern continue to work? |
|
There are a few minor details to work out but in general people seem okay with this. Are there any concerns remaining? |
|
Worth noting that if we accept this proposal we should probably decline #32450. |
I would think that that proposal would already be declined if the Go team is already resolved to not use semver. I don't see the connection between this proposal and that one. Both could be adopted, for example, because adding a 0 is compatible with semver. |
|
Many proposals are not declined simply because we haven't had bandwidth to give them a full hearing. "Not declined" != "still going to happen". But sure, we can keep it open instead. |
|
Based on the discussion above, this proposal seems like a likely accept. |
|
Just to clarify, what’s likely accept here? This proposal seems to talk about both renaming the first point release and changing the go.mod version string. Are these both likely accept or only the release renaming? |
|
Hi @tmthrgd, the forward compatibility proposal #57001 covers changing the However, as originally proposed, #57001 would have spelled the first Go 1.30 release in go.mod as This proposal is instead suggesting that the first Go 1.30 release would be spelled as In other words, if this proposal is accepted, it would affect both the general naming of the first point release as well as how it appears in go.mod. (On mobile; sorry if that’s unclear or if I misunderstood the question). |
|
Yes, the proposal here is that the official name of Go 1.21 will be "go1.21.0" when it appears in file names and the like. Similarly, the go.mod line will say |
|
No change in consensus, so accepted. 🎉 |
rsc
changed the title
The Docker images have included a synthetic |
Interesting, so the docker images are essentially tagging non-existing release versions 😆. |
Updates most of relui to put .0 at the end of major version numbers. Notably excluded is the GitHub milestone. For golang/go#57631 Change-Id: Ieca2afaf4a5af4e90321e0dd68ac750a0077753a Reviewed-on: https://go-review.googlesource.com/c/build/+/478577 Reviewed-by: Carlos Amedee <amedee@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Heschi Kreinick <heschi@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Heschi Kreinick <heschi@google.com>
Happily, the return values for 1.21 and 1.21.0 are the same, so I see no reason to worry about further impact. Just need to disable the now-unnecessary validation. For golang/go#57631 Change-Id: Ice467f993c1e5d304bd5b24fbc21bf4fa66fb4a4 Reviewed-on: https://go-review.googlesource.com/c/build/+/479556 Reviewed-by: Carlos Amedee <amedee@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Heschi Kreinick <heschi@google.com>
|
After further review, I believe the work for this is done. Dmitri will cross-check and close. |
rsc
changed the title
rsc
changed the title
|
Everything captured in #57631 (comment) looks good to me. In The release history page (https://go.dev/doc/devel/release) needs a small change to fix the "#go1.21.0" anchor that we'll be linking to in few places. I sent CL 497497 to fix that. The pkg.go.dev website may also need some updates in its stdlib package to be able to process future Go releases. I filed #60373 for that. Closing this as done. |
|
Change https://go.dev/cl/497497 mentions this issue: |
Now that proposal go.dev/issue/57631 is accepted, the upcoming major Go release version will not omit its trailing zero component in "go1.21.0". Update the behavior and documentation of Version accordingly. Drop IsMajor and IsMinor since they would need to be updated but aren't used anywhere. Instead, add MajorPrefix and use it to not break the future Go 1.21 release notes link. We decided those release notes document the entire release series, not just the first release, so it needs to eventually stay as "/doc/go1.21" and not "/doc/go1.21.0". For golang/go#57631. Change-Id: I069d171354752e5123b7950c45581a236b304f95 Reviewed-on: https://go-review.googlesource.com/c/website/+/497497 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
Change https://go.dev/cl/504521 mentions this issue: |
There's one more place to update for the upcoming go1.21.0 version name, the tweet announcing major releases. Increase the consistency between the templates and other similar code in the announcing, tweeting and mail-dl-cl tasks, to make them easier to maintain. The next CL will apply a few more simplifications. For golang/go#57631. Change-Id: I21957b05d14834f8d2d64a09a6f93bfb66ec228a Reviewed-on: https://go-review.googlesource.com/c/build/+/504521 Reviewed-by: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
|
Change https://go.dev/cl/515036 mentions this issue: |
We're still using Go1.N milestones to track major Go release development and need to update FetchMilestones to handle that as of go1.21.0, the .0 version component is explicitly included in the major version string. For golang/go#57631. Change-Id: I1dcc366796af2e3831ff866e957bcbb0967bdfe5 Reviewed-on: https://go-review.googlesource.com/c/build/+/515036 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
|
Change https://go.dev/cl/497498 mentions this issue: |
Go 1.21.0 is the first major Go release that explicitly includes the trailing ".0" version component. Add a test case covering changes to the history.Version type and the template that uses it. For golang/go#57631. Change-Id: I97581b650604c25b6996305ecf4ad9d883cd85ba Reviewed-on: https://go-review.googlesource.com/c/website/+/497498 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Summary
#32450 and #27255 proposed adopting semantic versioning for Go releases. semver has a very specific definition, which means fully adopting it has significant challenges, including it raises certain expectations that don't apply, there are differences between what the go project vs. semver considered a "major release", and other sample problems mentioned here or here. Personally, I don't think it would be worthwhile to adopt semver for Go releases.
This is intentionally a narrower proposal, which is just to start adding the
.0to major releases at some point, such asgo1.23.0.Rationale 1: Stop old releases from using code they don't understand
Part of the context for this proposal is the auto-upgrading forward compatibility proposal (#57001), which would be a transition point for how Go versions overall are managed, and the related possible transition in the semantics of loop variables (#56010).
In #57001 (comment), Russ wrote (responding to @rittneje):
Older go versions I think stretching back to go1.14 will reject a go.mod if the
goline has a go version with a third digit, so always using three digits in the go.mod could be a way to cause even very old versions of cmd/go to fail if for example #56010 is adopted.The majority of gophers would get the good behavior described in #57001 because most gophers would land within that K=1 or K=2 window, but this would be a broader enforcement mechanism that handles old Go releases outside that K window.
Example error (playground link):
In other words:
...which might be better than "unexpected semantics & no error" for that subset of gophers.
Rationale 2: Current source of confusion
I think releases like go1.20 have been a source of confusion, including when gophers are talking to each other about what version they are currently running or should run. Some older comments in a similar spirit:
@mvdan wrote in #29984:
@bcmills wrote in #29984:
Some costs
Code or scripts that parse go versions would need to be updated or at least visited to ensure they handle the new format.
go1.23.1might already handlego1.23.0).Documentation, blogs, books, and so on would also need to be updated or be slightly stale.
In general, using a transition point to introduce even more change is a terrible idea in some cases. In other cases, it can be helpful to piggyback a desirable change on top of another transition. That said, I'm not sure which of those cases this proposal is. ;-)
Alternative
An alternative form of this proposal might be to just use zero in the third digit in go.mod and nowhere else, which might be a smaller change, but that then might be a ~mild source of confusion if it is inconsistent with other go version uses.
The text was updated successfully, but these errors were encountered: