This is a more elaborate tutorial from the sparce release documentation for a first time release lead.
It follows the outline of the official release documentation Creating Release Candidate Patches.
At any point after the release candidate has been published but before the final stable release, some bugs related to this release might be fixed and committed to
trunk. These fixes won’t automatically be incorporated into the final stable release, including them is a manual process.
Becoming aware of need to backport to GB RC.
There are a couple of ways a release coordinator might be made aware of these bugs:
- Contributors may add the
Backport to Gutenberg RClabel to a closed PR. Do a search for any of these PRs before publishing the final release.
- You may receive a direct message or a ping in the #core-editor channel in slack notifying you of PRs that need to be included in the release candidate. Even when this is the case, the
Backport to Gutenberg RCshould be added to the PR.
- Release leads could also post a reminder to the #core-editor channel. Example from 15.6 release
The cherry-picking via Git commands
- Checkout the corresponding release branch with:
git checkout release/x.x.
- Cherry-pick fix commits (in chronological order) with
git cherry-pick [SHA].
- When done, push the changes to GitHub:
Tip: To find the `[SHA]` for a pull request, open the PR and near the end you’ll see a message “[Username] merged commit [SHA] into `trunk`”.
Example from 15.6 RC1: Revert PR 49646: “[Font API] Use registered fonts for Block Editor iframe.”#49863
Cherry Picking via NPM command
The cherry-picking process can also be automated with the
npm run cherry-pick script, using the
Backport to Gutenberg RC label when running the command.
# Switch to the release branch
git checkout release/X.Y
# Cherry-pick all the merged PRs with a relevant backport label
npm run other:cherry-pick "Backport to Gutenberg RC"
The advantage of the npm command over the series of git commands is that you don’t need to find the SHA, the process handles more than one PR and pushes the changes to the repo in one step.
Once the commits have been cherry-picked, remove the
Backport to Gutenberg RC label and update the milestone to the current release for all cherry-picked PRs.
If you decide that the fixes deserve another release candidate before the stable version is published, create one by following for Running the workflow.
You need to wait for the GitHub Actions from the `git push` to pass before you can start the RC2 (or RC3) workflow. It can take over 30 minutes to complete, depending on the PR and the end-to-end tests.
Example from 15.6 RC3:
Let other contributors know that a new release candidate has been released in the
#core-editor Slack channel.