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

all: reopen tree for Go 1.19 development #51336

Closed
3 tasks done
cagedmantis opened this issue Feb 23, 2022 · 12 comments
Closed
3 tasks done

all: reopen tree for Go 1.19 development #51336

cagedmantis opened this issue Feb 23, 2022 · 12 comments
Labels
early-in-cycle NeedsInvestigation umbrella
Milestone

Comments

@cagedmantis
Copy link
Contributor

@cagedmantis cagedmantis commented Feb 23, 2022

Current Tree Status: Tree open for all general Go 1.19 changes (see golang-dev announcement)

This is a tracking issue for the upcoming task of reopening the tree for Go 1.19 development. (It's created a little early to create room for planning early CLs/branches to land during tree reopening.)

As usual, the tree will initially be open to changes that must land early:

  • Bump internal/goversion.Version to 19—this should be the very first CL to be submitted as it marks the start of master branch representing Go 1.19 (rather than Go 1.18). (Example CL.)
  • Early in cycle CLs.
  • Finally, open the tree for all general Go 1.19 changes.

CC @golang/release.

@cagedmantis cagedmantis added NeedsInvestigation early-in-cycle umbrella labels Feb 23, 2022
@cagedmantis cagedmantis added this to the Go1.19 milestone Feb 23, 2022
@cagedmantis cagedmantis self-assigned this Feb 23, 2022
@cagedmantis
Copy link
Contributor Author

@cagedmantis cagedmantis commented Feb 23, 2022

cc @mdempsky Please add any changes you have queued up.

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 28, 2022

Change https://go.dev/cl/388376 mentions this issue: internal/goversion: update Version to 1.19

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Feb 28, 2022

@cagedmantis My outstanding CLs for Go 1.19 are the stack leading up to go.dev/cl/384000, but I don't think they need to hold up reopening the tree. They're still in review and aren't likely to conflict with other work anyway. I think they can roll in alongside other CLs.

@cagedmantis
Copy link
Contributor Author

@cagedmantis cagedmantis commented Feb 28, 2022

Thanks for the feedback @mdempsky. We are starting the process of opening up the tree.

gopherbot pushed a commit that referenced this issue Feb 28, 2022
This is the start of the Go 1.19 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).

Updates #40705
Updates #51336

Change-Id: Ic4b3f2c04b1fa5c588cb6d62e829f2ed1864e511
Reviewed-on: https://go-review.googlesource.com/c/go/+/388376
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
Trust: Alex Rakoczy <alex@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Alex Rakoczy <alex@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
@cagedmantis
Copy link
Contributor Author

@cagedmantis cagedmantis commented Feb 28, 2022

There aren't any early-in-cycle CLs.

@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Feb 28, 2022

This is a half related question, but with 1.18 branched off and master now being marked as the start of 1.19, are all of the fixes submitted for things like generics going to be merged back into the 1.18 branch? That branch was last updated 2 weeks ago and there's a load of 1.18 milestone issues that were submitted to master, and I was expecting them to get merged into the 1.18 release branch before the 1.19 version change was committed (but now, that doesn't seem likely).

@cagedmantis cagedmantis added this to In Progress in Go Release Team Mar 1, 2022
@cagedmantis
Copy link
Contributor Author

@cagedmantis cagedmantis commented Mar 1, 2022

@zikaeroh All Go 1.18 fixes will be merged into the release-branch.go1.18 before the next release. Any 1.18 changes that arrive on the master branch after bumping the version in master to 1.19 will be cherry picked back to the release-branch.go1.18 branch.

@cagedmantis
Copy link
Contributor Author

@cagedmantis cagedmantis commented Mar 1, 2022

Closing this issue as the tree is now open.

Go Release Team automation moved this from In Progress to Done Mar 1, 2022
@randall77
Copy link
Contributor

@randall77 randall77 commented Mar 1, 2022

Just to be clear, CLs submitted to master now need a corresponding issue with milestone 1.18 in order to be cherry-picked back to 1.18? Or is there some other process for identifying them?

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Mar 1, 2022

@randall77 Yes, using an issue in Go1.18 milestone makes sense. I'm not sure what is the most optimal way to identify such "for 1.18" CLs, so maybe there are even better ways.

For things that are very important to make it into the final Go 1.18 release, I'd suggest the approach used in #51209 (comment), that is to make sure the issue in the Go1.18 milestone has release-blocker label and stays open until the cherry-pick to release-branch.go1.18 has landed. (Our release tooling catches issues with release-blocker label in the target milestone that are still-open, so it couldn't be missed.)

@griesemer
Copy link
Contributor

@griesemer griesemer commented Mar 2, 2022

I like to strongly suggest that we update/cherry-pick to the release branch now to avoid any last-minute issues. Specifically, it should be moved forward to the commit just before the 1.19 tree opened, and any already pending 1.18 CLs should be cherry-picked.

I am not assuming a lot more 1.18 changes but there may be additional updates to the release notes, and definitely updates to the spec. If we keep the release branch up-to-date we can a) verify that important CLs are in by looking at release-branch.go1.18, and b), if there are problems we can check out that branch and investigate. CL authors can also do the cherry-picking themselves, with approval from the release team, which should further reduce potential problems.

If there are incoming issues it will be difficult to decide if the issue is in the release or if it has been already fixed. In summary, I think cherry-picking at the end is inviting problems.

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Mar 4, 2022

Thanks for making that suggestion Robert. There's widespread agreement that it's a good idea to start updating release-branch.go1.18 sooner.

We've created an umbrella tracking issue #51460 that collects (and sorts) all outstanding CLs that are intended to be cherry-picked from master to Go 1.18 release branch. If something is missing or needs to be done differently, that is the issue to leave a comment on. In #51460 (comment) there's a stack of cherry-picks prepared, so it is possible to check out the tip of that stack to test what the release-branch.go1.18 branch is shaping up to be, even before they're submitted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
early-in-cycle NeedsInvestigation umbrella
Projects
Development

No branches or pull requests

7 participants