@@ -175,10 +175,10 @@ duplicate or not.
175
175
For a list of commits that could be landed in a patch release on v1.x:
176
176
177
177
``` console
178
- $ 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
178
+ $ branch-diff v1.x-staging master --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-requested-v1.x,backport-blocked-v1.x --filter-release --format=simple
179
179
```
180
180
181
- Previous release commits and version bumps do not need to be
181
+ Previously released commits and version bumps do not need to be
182
182
cherry-picked.
183
183
184
184
Carefully review the list of commits:
@@ -187,17 +187,30 @@ Carefully review the list of commits:
187
187
* Checking semver status - Commits labeled as ` semver-minor ` or ` semver-major `
188
188
should only be cherry-picked when appropriate for the type of release being
189
189
made.
190
- * If you think it's risky so should wait for a while, add the ` baking-for-lts `
191
- tag.
190
+ * If you think it's risky and the change should wait for a while, add the
191
+ ` baking-for-lts ` tag.
192
+
193
+ When you are ready to cherry-pick commits, you can automate with the following
194
+ command. (For semver-minor releases, make sure to remove the ` semver-minor ` tag
195
+ from ` exclude-label ` .)
196
+
197
+ ``` console
198
+ $ branch-diff v1.x-staging master --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-requested-v1.x,backport-blocked-v1.x --filter-release --format=sha --reverse | xargs git cherry-pick
199
+ ```
192
200
193
201
When cherry-picking commits, if there are simple conflicts you can resolve
194
202
them. Otherwise, add the ` backport-requested-vN.x ` label to the original PR
195
203
and post a comment stating that it does not land cleanly and will require a
196
204
backport PR. You can refer the owner of the PR to the "[ Backporting to Release
197
205
Lines] ( https://github.com/nodejs/node/blob/HEAD/doc/guides/backporting-to-release-lines.md ) " guide.
198
206
199
- If commits were cherry-picked in this step, check that the test still pass and
200
- push to the staging branch to keep it up-to-date.
207
+ If commits were cherry-picked in this step, check that the test still pass.
208
+
209
+ ``` console
210
+ $ make test
211
+ ```
212
+
213
+ Then, push to the staging branch to keep it up-to-date.
201
214
202
215
``` console
203
216
$ git push upstream v1.x-staging
@@ -274,9 +287,11 @@ in the repository was not on the current branch you may have to supply a
274
287
` --start-ref ` argument:
275
288
276
289
``` console
277
- $ changelog-maker --group --start-ref v1.2.2
290
+ $ changelog-maker --group --filter-release -- start-ref v1.2.2
278
291
```
279
292
293
+ ` --filter-release ` will remove the release commit from the previous release.
294
+
280
295
#### Step 2: Update the appropriate doc/changelogs/CHANGELOG_ * .md file
281
296
282
297
There is a separate ` CHANGELOG_Vx.md ` file for each major Node.js release line.
0 commit comments