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

x/build: increment internal/goversion at the beginning of the release cycle #38704

heschi opened this issue Apr 27, 2020 · 5 comments

x/build: increment internal/goversion at the beginning of the release cycle #38704

heschi opened this issue Apr 27, 2020 · 5 comments


Copy link

@heschi heschi commented Apr 27, 2020

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.)


Copy link

@dmitshur dmitshur commented Apr 27, 2020

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:

  • Bumped to 1.14 on Oct 1, 2019 (28 days away from Go 1.13 release)
  • Bumped to 1.13 on Feb 20, 2019 (5 days away from Go 1.12 release)
  • Bumped to 1.12 on Nov 2, 2018 (70 days away from Go 1.11 release)
  • Bumped to 1.11 on Feb 13, 2018 (3 days away from Go 1.10 release)
  • Bumped to 1.10 on Aug 25, 2017 (1 day away from Go 1.9 release)

Doing it predictably at the beginning of the development cycle should be an improvement.

/cc @cagedmantis @toothrot @andybons

@dmitshur dmitshur self-assigned this Apr 27, 2020
Copy link

@dmitshur dmitshur commented Apr 29, 2020

We've added this step to an internal part of release process, so it should happen for the next release and onwards. Closing.

@dmitshur dmitshur closed this Apr 29, 2020
Copy link

@gopherbot gopherbot commented May 21, 2020

Change mentions this issue: all: replace build tags in tests with testenv helper

gopherbot pushed a commit to golang/tools that referenced this issue May 27, 2020
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
Run-TryBot: Heschi Kreinick <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Robert Findley <>
Copy link

@dmitshur dmitshur commented Aug 11, 2020

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.

Copy link

@gopherbot gopherbot commented Aug 11, 2020

Change mentions this issue: internal/goversion: update Version to 1.16

gopherbot pushed a commit that referenced this issue Aug 12, 2020
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-by: Carlos Amedee <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants