Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: update main branch name in release guide #43437

Merged
merged 2 commits into from
Jun 16, 2022
Merged

doc: update main branch name in release guide #43437

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9311408
doc: update main branch name in release guide
richardlau Jun 15, 2022
6fd1b1c
fixup! doc: update main branch name in release guide
richardlau Jun 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 13 additions & 13 deletions doc/contributing/releases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ official release builds for Node.js, hosted on <https://nodejs.org/>.
* [10. Test the build](#10-test-the-build)
* [11. Tag and sign the release commit](#11-tag-and-sign-the-release-commit)
* [12. Set up for the next release](#12-set-up-for-the-next-release)
* [13. Cherry-pick the release commit to `master`](#13-cherry-pick-the-release-commit-to-master)
* [13. Cherry-pick the release commit to `main`](#13-cherry-pick-the-release-commit-to-main)
* [14. Push the release tag](#14-push-the-release-tag)
* [15. Promote and sign the release builds](#15-promote-and-sign-the-release-builds)
* [16. Check the release](#16-check-the-release)
Expand Down Expand Up @@ -132,7 +132,7 @@ tracker][].

When preparing a security release, contact Build at least two weekdays in
advance of the expected release. To ensure that the security patch(es) can be
properly tested, run a `node-test-pull-request` job against the `master` branch
properly tested, run a `node-test-pull-request` job against the `main` branch
of the `nodejs-private/node-private` repository a day or so before the
[CI lockdown procedure][] begins. This is to confirm that Jenkins can properly
access the private repository.
Expand All @@ -147,7 +147,7 @@ $ git checkout v1.x-staging
$ 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 `main`, bring the
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).
Expand All @@ -156,7 +156,7 @@ 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.
* Check that the commit metadata was not changed from the `main` commit.
* If there are merge conflicts, ask the PR author to rebase.
Simple conflicts can be resolved when landing.

Expand All @@ -175,7 +175,7 @@ duplicate or not.
For a list of commits that could be landed in a patch release on v1.x:

```console
$ 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,backport-open-v1.x,backported-to-v1.x --filter-release --format=simple
$ branch-diff v1.x-staging main --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-requested-v1.x,backport-blocked-v1.x,backport-open-v1.x,backported-to-v1.x --filter-release --format=simple
```

Previously released commits and version bumps do not need to be
Expand All @@ -195,7 +195,7 @@ command. (For semver-minor releases, make sure to remove the `semver-minor` tag
from `exclude-label`.)

```console
$ 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,backport-open-v1.x,backported-to-v1.x --filter-release --format=sha --reverse | xargs git cherry-pick
$ branch-diff v1.x-staging main --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-requested-v1.x,backport-blocked-v1.x,backport-open-v1.x,backported-to-v1.x --filter-release --format=sha --reverse | xargs git cherry-pick
```

When cherry-picking commits, if there are simple conflicts you can resolve
Expand Down Expand Up @@ -387,7 +387,7 @@ release branches to more easily be passed between members of the release team if
necessary.

Create a pull request targeting the correct release line. For example, a
`v5.3.0-proposal` PR should target `v5.x`, not master. Paste the CHANGELOG
`v5.3.0-proposal` PR should target `v5.x`, not main. Paste the CHANGELOG
richardlau marked this conversation as resolved.
Show resolved Hide resolved
modifications into the body of the PR so that collaborators can see what is
changing. These PRs should be left open for at least 24 hours, and can be
updated as new commits land. If the CHANGELOG pasted into the pull request
Expand Down Expand Up @@ -540,10 +540,10 @@ $ git rebase v1.x
$ git push upstream v1.x-staging
```

### 13. Cherry-pick the release commit to `master`
### 13. Cherry-pick the release commit to `main`

```console
$ git checkout master
$ git checkout main
$ git cherry-pick v1.x^
```

Expand All @@ -565,10 +565,10 @@ Then finish cherry-picking and push the commit upstream:
$ git add src/node_version.h doc
$ git cherry-pick --continue
$ make lint
$ git push upstream master
$ git push upstream main
```

**Do not** cherry-pick the "Working on vx.y.z" commit to `master`.
**Do not** cherry-pick the "Working on vx.y.z" commit to `main`.

### 14. Push the release tag

Expand Down Expand Up @@ -798,8 +798,8 @@ announced immediately following the release of 12.0.0).

Approximately two months before a major release, new `vN.x` and
`vN.x-staging` branches (where `N` indicates the major release) should be
created as forks of the `master` branch. Up until one week before the release
date, these must be kept in sync with `master`.
created as forks of the `main` branch. Up until one week before the release
date, these must be kept in sync with `main`.

The `vN.x` and `vN.x-staging` branches must be kept in sync with one another
up until the date of the release.
Expand Down