cybercyst/go
1
0
Fork 0
mirror of https://github.com/golang/go.git synced 2025-05-05 15:43:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Updated MinorReleases (markdown)

Filippo Valsorda 2018-04-23 15:46:30 -04:00
parent e281bf21af
commit 6a0db9a041
1 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
MinorReleases.md

@ -1,6 +1,6 @@
Fixes for regressions, security issues, and serious problems with no workaround are backported to the two supported major releases. For example a fix developed during the 1.11 cycle will be backported to a 1.9.x (if applicable) and 1.10.x release.
As soon as an interested party thinks an issue should be considered for backport, they open one or two “child” issues titled like `package: title [1.9 backport]`. The issue should include a link to the original issue, the CLs that need to be cherry-picked (if one exists), and a short rationale about why the backport might be needed.
As soon as an interested party thinks an issue should be considered for backport, they open one or two “child” issues titled like `package: title [1.9 backport]`. The issue should include a link to the original issue and a short rationale about why the backport might be needed.
GopherBot is capable of opening the backport issues automatically in response to comments like the following on the main issue. (The keywords are `@gopherbot`, `backport`, `please` and optionally the release. The entire message is quoted in the new issue.)
@ -10,9 +10,9 @@ GopherBot is capable of opening the backport issues automatically in response to
The fix is developed for the main issue, which is closed when the fix is merged to the master branch.
The child issue is assigned to the minor release milestone, is labeled **CherryPickCandidate**, and its candidacy is discussed there. Once it’s approved it transitions to **CherryPickApproved**. Release managers and/or code owners approve cherry-picks via an informal process.
The child issue is assigned to the minor release milestone and labeled **CherryPickCandidate**, and its candidacy is discussed there. Once it is approved it transitions to **CherryPickApproved**. Release managers (a subset of the Go team that handles the release process) and/or code owners approve cherry-picks via an informal process.
The original change author should immediately create and mail a cherry-pick change against the release branch, which will be merged as soon as it's ready, closing the child issue.
When the child issue is labeled **CherryPickApproved**, the original change author should immediately [create and mail a cherry-pick change](#making-cherry-pick-cls) against the release branch, which will be merged as soon as it is ready, closing the child issue.
At release time, any open backport issue which is not release-blocker is pushed to the next minor release milestone, and a minor release is minted with the already merged changes.
@ -20,9 +20,15 @@ At release time, any open backport issue which is not release-blocker is pushed
Once the main fix has been submitted to master, take note of its commit hash.
TODO
```
git codereview change release-branch.go1.10
git codereview change cherry-pick-NNNN
git cherry-pick $COMMIT_HASH
git commit --amend # add message prefix and change Fixes line
git codereview mail
```
The cherry-pick CL must include a message prefix like `[release-branch.go1.10]`, and update the "Fixes" line to the child issue.
The cherry-pick CL must include a message prefix like `[release-branch.go1.10]`, and update the "Fixes" line to the child issue. Do not change the "Change-Id" line.
Gerrit is configured to only allow release managers to submit to release branches, but the code review process is otherwise the usual.