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

Closed
heschi opened this issue Apr 27, 2020 · 5 comments
Closed
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@heschi
Copy link
Contributor

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

@dmitshur

@gopherbot gopherbot added this to the Unreleased milestone Apr 27, 2020
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Apr 27, 2020
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 27, 2020
@dmitshur
Copy link
Contributor

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
@dmitshur
Copy link
Contributor

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

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/234882 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
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>
@dmitshur
Copy link
Contributor

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.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/248038 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-on: https://go-review.googlesource.com/c/go/+/248038
Reviewed-by: Carlos Amedee <carlos@golang.org>
rinchsan pushed a commit to rinchsan/gosimports that referenced this issue May 30, 2021
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>
@golang golang locked and limited conversation to collaborators Aug 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

3 participants