1berry/nodejs
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

doc: add triaging section to releases.md

Browse Source 
Add a section on triaging commits and PRs to land in releases.

PR-URL: https://github.com/nodejs/node/pull/20165
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
This commit is contained in:
Beth Griggs 2018-04-19 18:11:23 +01:00 committed by Rich Trott
parent e9a1fee818
commit a845d7a93d
1 changed files with 32 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
doc/releases.md
View File

@ -138,7 +138,22 @@ $ git reset --hard upstream/v1.x-staging
``` ```
If the staging branch is not up to date relative to `master`, bring the If the staging branch is not up to date relative to `master`, bring the
appropriate commits into it. To determine the relevant commits, use appropriate PRs and commits into it.
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).
For each PR:
- Run or check that there is a passing CI.
- Check approvals (you can approve yourself).
- Check that the commit metadata was not changed from the `master` commit.
- If there are merge conflicts, ask the PR author to rebase.
Simple conflicts can be resolved when landing.
When landing the PR add the `Backport-PR-URL:` line to each commit. Close the
backport PR with `Landed in ...`. Update the label on the original PR from
`backport-requested-vN.x` to `backported-to-vN.x`.
To determine the relevant commits, use
[`branch-diff`](https://github.com/nodejs/branch-diff). The tool is available on [`branch-diff`](https://github.com/nodejs/branch-diff). The tool is available on
npm and should be installed globally or run with `npx`. It depends on our commit npm and should be installed globally or run with `npx`. It depends on our commit
metadata, as well as the GitHub labels such as `semver-minor` and 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:
$ 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 $ 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
``` ```
Carefully review the list of commits looking for errors (incorrect `PR-URL`, Previous release commits and version bumps do not need to be
incorrect semver, etc.). Commits labeled as `semver-minor` or `semver-major`
should only be cherry-picked when appropriate for the type of release being
made. Previous release commits and version bumps do not need to be
cherry-picked. cherry-picked.
If commits were cherry-picked in this step, push to the staging branch to keep Carefully review the list of commits:
it up-to-date. - Checking for errors (incorrect `PR-URL`)
- Checking semver status - Commits labeled as `semver-minor` or `semver-major`
should only be cherry-picked when appropriate for the type of release being
made.
- If you think it's risky so should wait for a while, add the `baking-for-lts`
tag.
When cherry-picking commits, if there are simple conflicts you can resolve
them. Otherwise, add the `backport-requested-vN.x` label to the original PR
and post a comment stating that it does not land cleanly and will require a
backport PR.
If commits were cherry-picked in this step, check that the test still pass and
push to the staging branch to keep it up-to-date.
```console ```console
$ git push upstream v1.x-staging $ git push upstream v1.x-staging