all: reopen tree for Go 1.19 development

[cagedmantis]

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.)
  • internal/goversion: increment Version at start of cycle #40705
  • CL 388376: internal/goversion: update Version to 1.19
• Early in cycle CLs.
• Finally, open the tree for all general Go 1.19 changes.

CC @golang/release.

[cagedmantis]

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

[gopherbot]

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

[mdempsky]

@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]

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

[cagedmantis]

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

[zikaeroh]

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]

@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]

Closing this issue as the tree is now open.

[randall77]

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]

@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]

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]

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.