Cherry-picking during release process of the Gutenberg plugin

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 RC label 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 RC should 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

1. Checkout the corresponding release branch with: git checkout release/x.x.
2. Cherry-pick fix commits (in chronological order) with git cherry-pick [SHA].
3. When done, push the changes to GitHub: git push.

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.