-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/build: increment internal/goversion at the beginning of the release cycle #38704
Comments
Thanks for reporting. I agree we should ensure this is done at an appropriate time, and not forgotten if someone doesn't send a CL manually. Looking at some historical data, this used to be done anywhere between very early and late in the development cycle:
Doing it predictably at the beginning of the development cycle should be an improvement. |
We've added this step to an internal part of release process, so it should happen for the next release and onwards. Closing. |
Change https://golang.org/cl/234882 mentions this issue: |
Many tool features, particularly modules-related, require particular Go versions. Build tags are unwieldy, requiring one-off test files which break up test organization. Add a suite of testenv functions that check what Go version is in use. Note that this is the logical Go version, as denoted by the release tags; it should be updated at the beginning of the release cycle per issue golang/go#38704. For ease of reviewing, I'll merge/delete files in a followup CL. Change-Id: Id85ce0f83387b3c45d68465161cf88447325d4f2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/234882 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
I've created a recurring release-blocking issue to make this internal part of the release process more visible and easier to track, see #40705. |
Change https://golang.org/cl/248038 mentions this issue: |
This is the start of the Go 1.16 development cycle, so update the Version value accordingly. It represents the Go 1.x version that will soon open up for development (and eventually become released). Historically, we used to bump this at an arbitrary time throughout the development cycle, but it's better to be more predictable about updating it. The start of a development cycle should be the most appropriate time: it clearly marks the boundary between 1.15 and 1.16 development, and doing it early can help catch issues in other tooling. See issue #38704 for more background. There is no longer a need to update the list of Go versions in src/go/build/doc.go because it does not exist as of CL 232981. For #40705. Updates #38704. Updates #37018. Change-Id: Id8ee733b5e79c53b6cd03509c6560614d8743833 Reviewed-on: https://go-review.googlesource.com/c/go/+/248038 Reviewed-by: Carlos Amedee <carlos@golang.org>
Many tool features, particularly modules-related, require particular Go versions. Build tags are unwieldy, requiring one-off test files which break up test organization. Add a suite of testenv functions that check what Go version is in use. Note that this is the logical Go version, as denoted by the release tags; it should be updated at the beginning of the release cycle per issue golang/go#38704. For ease of reviewing, I'll merge/delete files in a followup CL. Change-Id: Id85ce0f83387b3c45d68465161cf88447325d4f2 Reviewed-on: https://go-review.googlesource.com/c/tools/+/234882 Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
internal/goversion determines what release tags are in effect. It should be incremented at the beginning of each cycle as part of unfreezing the tree, otherwise who knows when someone will remember to do it. (I just noticed a couple days ago, the week before the freeze. It's not clear to me anyone would have caught it before the beta.)
@dmitshur
The text was updated successfully, but these errors were encountered: