@@ -138,7 +138,22 @@ $ git reset --hard upstream/v1.x-staging |
138 | 138 | ``` |
139 | 139 |
|
140 | 140 | If the staging branch is not up to date relative to `master`, bring the |
141 | | -appropriate commits into it. To determine the relevant commits, use |
| 141 | +appropriate PRs and commits into it. |
| 142 | + |
| 143 | +Go through PRs with the label `vN.x`. e.g. [PRs with the `v8.x` label](https://github.com/nodejs/node/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Av8.x). |
| 144 | + |
| 145 | +For each PR: |
| 146 | +- Run or check that there is a passing CI. |
| 147 | +- Check approvals (you can approve yourself). |
| 148 | +- Check that the commit metadata was not changed from the `master` commit. |
| 149 | +- If there are merge conflicts, ask the PR author to rebase. |
| 150 | +Simple conflicts can be resolved when landing. |
| 151 | + |
| 152 | +When landing the PR add the `Backport-PR-URL:` line to each commit. Close the |
| 153 | +backport PR with `Landed in ...`. Update the label on the original PR from |
| 154 | +`backport-requested-vN.x` to `backported-to-vN.x`. |
| 155 | + |
| 156 | +To determine the relevant commits, use |
142 | 157 | [`branch-diff`](https://github.com/nodejs/branch-diff). The tool is available on |
143 | 158 | npm and should be installed globally or run with `npx`. It depends on our commit |
144 | 159 | metadata, as well as the GitHub labels such as `semver-minor` and |
@@ -152,14 +167,24 @@ For a list of commits that could be landed in a patch release on v1.x: |
152 | 167 | $ branch-diff v1.x-staging master --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-requested-v1.x --filter-release --format=simple |
153 | 168 | ``` |
154 | 169 |
|
155 | | -Carefully review the list of commits looking for errors (incorrect `PR-URL`, |
156 | | -incorrect semver, etc.). Commits labeled as `semver-minor` or `semver-major` |
157 | | -should only be cherry-picked when appropriate for the type of release being |
158 | | -made. Previous release commits and version bumps do not need to be |
| 170 | +Previous release commits and version bumps do not need to be |
159 | 171 | cherry-picked. |
160 | 172 |
|
161 | | -If commits were cherry-picked in this step, push to the staging branch to keep |
162 | | -it up-to-date. |
| 173 | +Carefully review the list of commits: |
| 174 | +- Checking for errors (incorrect `PR-URL`) |
| 175 | +- Checking semver status - Commits labeled as `semver-minor` or `semver-major` |
| 176 | +should only be cherry-picked when appropriate for the type of release being |
| 177 | +made. |
| 178 | +- If you think it's risky so should wait for a while, add the `baking-for-lts` |
| 179 | + tag. |
| 180 | + |
| 181 | +When cherry-picking commits, if there are simple conflicts you can resolve |
| 182 | +them. Otherwise, add the `backport-requested-vN.x` label to the original PR |
| 183 | +and post a comment stating that it does not land cleanly and will require a |
| 184 | +backport PR. |
| 185 | + |
| 186 | +If commits were cherry-picked in this step, check that the test still pass and |
| 187 | +push to the staging branch to keep it up-to-date. |
163 | 188 |
|
164 | 189 | ```console |
165 | 190 | $ git push upstream v1.x-staging |
|