Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
x/build: increment internal/goversion at the beginning of the release cycle #38704
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.)
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.
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 <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Robert Findley <email@example.com>
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 <firstname.lastname@example.org>