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

doc: update main branch name in doc/contributing/*

Browse Source 
Refs: https://github.com/nodejs/node/issues/33864

PR-URL: https://github.com/nodejs/node/pull/43438
Reviewed-By: Richard Lau <rlau@redhat.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Darshan Sen <raisinten@gmail.com>
Reviewed-By: LiviaMedeiros <livia@cirno.name>
Reviewed-By: Rich Trott <rtrott@gmail.com>
This commit is contained in:
Luigi Pinca 2022-06-16 15:10:56 +02:00 committed by GitHub
parent 6975dd1425
commit 7bf50bc26a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
11 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/contributing/backporting-to-release-lines.md
View File

@ -10,7 +10,7 @@ For the active staging branches see the [Release Schedule][].
## What needs to be backported?
If a cherry-pick from master does not land cleanly on a staging branch, the
If a cherry-pick from `main` does not land cleanly on a staging branch, the
releaser will mark the pull request with a particular label for that release
line (e.g. `backport-requested-vN.x`), specifying to our tooling that this
pull request should not be included. The releaser will then add a comment

44
doc/contributing/collaborator-guide.md
View File

@ -287,11 +287,11 @@ in the form:
* `GIT_REMOTE_REF`: Change to the remote portion of git refspec.
To specify the branch this way, `refs/heads/BRANCH` is used
(e.g. for `master` -> `refs/heads/master`).
(e.g. for `main` -> `refs/heads/main`).
For pull requests, it will look like `refs/pull/PR_NUMBER/head`
(e.g. for pull request #42 -> `refs/pull/42/head`).
* `REBASE_ONTO`: Change that to `origin/master` so the pull request gets rebased
onto master. This can especially be important for pull requests that have been
* `REBASE_ONTO`: Change that to `origin/main` so the pull request gets rebased
onto `main`. This can especially be important for pull requests that have been
open a while.
Look at the list of jobs on the left hand side under "Build History" and copy
@ -337,7 +337,7 @@ For undocumented APIs that are public, open a pull request documenting the API.
### Breaking changes
At least two TSC members must approve backward-incompatible changes to the
master branch.
`main` branch.
Examples of breaking changes include:
@ -373,7 +373,7 @@ providing a Public API in such cases.
#### Unintended breaking changes
Sometimes, a change intended to be non-breaking turns out to be a breaking
change. If such a change lands on the master branch, a collaborator can revert
change. If such a change lands on the `main` branch, a collaborator can revert
it. As an alternative to reverting, the TSC can apply the semver-major label
after-the-fact.
@ -462,7 +462,7 @@ duration.
Communicate pending deprecations and associated mitigations with the ecosystem
as soon as possible. If possible, do it before the pull request adding the
deprecation lands on the master branch.
deprecation lands on the `main` branch.
Use the `notable-change` label on pull requests that add or change the
deprecation level of an API.
@ -554,7 +554,7 @@ $ git rebase --abort
Checkout proper target branch:
```text
$ git checkout master
$ git checkout main
```
Update the tree (assumes your repository is set up as detailed in
@ -562,7 +562,7 @@ Update the tree (assumes your repository is set up as detailed in
```text
$ git fetch upstream
$ git merge --ff-only upstream/master
$ git merge --ff-only upstream/main
```
Apply external patches:
@ -588,19 +588,19 @@ has landed since the CI run. You will have to ask the author to rebase.
Check and re-review the changes:
```text
$ git diff upstream/master
$ git diff upstream/main
```
Check the number of commits and commit messages:
```text
$ git log upstream/master...master
$ git log upstream/main...main
```
Squash commits and add metadata:
```text
$ git rebase -i upstream/master
$ git rebase -i upstream/main
```
This will open a screen like this (in the default shell editor):
@ -670,19 +670,19 @@ for that commit. This is an opportunity to fix commit messages.
pull request.
* Protects against the assumption that GitHub will be around forever.
Other changes might have landed on master since the successful CI run. As a
Other changes might have landed on `main` since the successful CI run. As a
precaution, run tests (`make -j4 test` or `vcbuild test`).
Confirm that the commit message format is correct using
[core-validate-commit](https://github.com/nodejs/core-validate-commit).
```text
$ git rev-list upstream/master...HEAD | xargs core-validate-commit
$ git rev-list upstream/main...HEAD | xargs core-validate-commit
```
Optional: For your own commits, force push the amended commit to the pull
request branch. If your branch name is `bugfix`, then:
`git push --force-with-lease origin master:bugfix`. Don't close the pull
`git push --force-with-lease origin main:bugfix`. Don't close the pull
request. It will close after you push it upstream. It will have the purple
merged status rather than the red closed status. If you close the pull request
before GitHub adjusts its status, it will show up as a 0 commit pull
@ -693,7 +693,7 @@ the issue with the red closed status.
Time to push it:
```text
$ git push upstream master
$ git push upstream main
```
Close the pull request with a "Landed in `<commit hash>`" comment. Even if
@ -705,12 +705,12 @@ more than one commit.
### Troubleshooting
Sometimes, when running `git push upstream master`, you might get an error
Sometimes, when running `git push upstream main`, you might get an error
message like this:
```console
To https://github.com/nodejs/node
! [rejected] master -> master (fetch first)
! [rejected] main -> main (fetch first)
error: failed to push some refs to 'https://github.com/nodejs/node'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
@ -718,14 +718,14 @@ hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
```
That means a commit has landed since your last rebase against `upstream/master`.
That means a commit has landed since your last rebase against `upstream/main`.
To fix this, pull with rebase from upstream, run the tests again, and (if the
tests pass) push again:
```bash
git pull upstream master --rebase
git pull upstream main --rebase
make -j4 test
git push upstream master
git push upstream main
```
### I made a mistake
@ -755,7 +755,7 @@ the branch.
Each LTS release has a corresponding branch (v10.x, v8.x, etc.). Each also has a
corresponding staging branch (v10.x-staging, v8.x-staging, etc.).
Commits that land on master are cherry-picked to each staging branch as
Commits that land on `main` are cherry-picked to each staging branch as
appropriate. If a change applies only to the LTS branch, open the pull request
against the _staging_ branch. Commits from the staging branch land on the LTS
branch only when a release is being prepared. They might land on the LTS branch
@ -901,7 +901,7 @@ We use labels to keep track of which branches a commit should land on:
* (for example semver-minor changes that need or should go into an LTS
release)
* `v?.x`
* Automatically applied to changes that do not target `master` but rather the
* Automatically applied to changes that do not target `main` but rather the
`v?.x-staging` branch
Once a release line enters maintenance mode, the corresponding labels do not

4
doc/contributing/commit-queue.md
View File

@ -8,7 +8,7 @@ Commit Queue is an experimental feature for the project which simplifies the
landing process by automating it via GitHub Actions. With it, collaborators can
land pull requests by adding the `commit-queue` label to a PR. All
checks will run via node-core-utils, and if the pull request is ready to land,
the Action will rebase it and push to master.
the Action will rebase it and push to `main`.
This document gives an overview of how the Commit Queue works, as well as
implementation details, reasoning for design choices, and current limitations.
@ -108,7 +108,7 @@ forwarding stdout and stderr to a file. If any errors happen,
to the PR, as well as a comment with the output of `git node land`.
If no errors happen during `git node land`, the script will use the
`GITHUB_TOKEN` to push the changes to `master`, and then will leave a
`GITHUB_TOKEN` to push the changes to `main`, and then will leave a
`Landed in ...` comment in the PR, and then will close it. Iteration continues
until all PRs have done the steps above.

2
doc/contributing/diagnostic-tooling-support-tiers.md
View File

@ -14,7 +14,7 @@ the following tiers.
suite for the tool/API is not green. To be considered for inclusion
in this tier it must have a good test suite and that test suite and a job
must exist in the Node.js CI so that it can be run as part of the release
process. Tests on master will be run nightly when possible to provide
process. Tests on `main` will be run nightly when possible to provide
early warning of potential issues. No commit to the current and LTS
release branches should break this tool/API if the next major release
is within 1 month. In addition:

12
doc/contributing/maintaining-V8.md
View File

@ -326,12 +326,12 @@ The rough outline of the process is:
```bash
# Assuming your fork of Node.js is checked out in $NODE_DIR
# and you want to update the Node.js master branch.
# and you want to update the Node.js main branch.
# Find the current (OLD) version in
# $NODE_DIR/deps/v8/include/v8-version.h
cd $NODE_DIR
git checkout master
git merge --ff-only origin/master
git checkout main
git merge --ff-only origin/main
git checkout -b V8_NEW_VERSION
curl -L https://github.com/v8/v8/compare/${V8_OLD_VERSION}...${V8_NEW_VERSION}.patch | git apply --directory=deps/v8
# You may want to amend the commit message to describe the nature of the update
@ -345,13 +345,13 @@ to apply a minor update.
### Major updates
We upgrade the version of V8 in Node.js master whenever a V8 release goes stable
We upgrade the version of V8 in Node.js `main` whenever a V8 release goes stable
upstream, that is, whenever a new release of Chrome comes out.
Upgrading major versions would be much harder to do with the patch mechanism
above. A better strategy is to
1. Audit the current master branch and look at the patches that have been
1. Audit the current `main` branch and look at the patches that have been
floated since the last major V8 update.
2. Replace the copy of V8 in Node.js with a fresh checkout of the latest stable
V8 branch. Special care must be taken to recursively update the DEPS that V8
@ -394,7 +394,7 @@ branches. This has several benefits:
* The history of the V8 branch in `nodejs/v8` becomes purer and it would make it
easier to pull in the V8 team for help with reviewing.
* It would make it simpler to setup an automated build that tracks Node.js
master + V8 lkgr integration build.
`main` + V8 lkgr integration build.
This would require some tooling to:

2
doc/contributing/maintaining-cjs-module-lexer.md
View File

@ -17,7 +17,7 @@ implementation using WebAssembly which is generated from a
C based implementation. These two paths
resolve to the files in `deps/cjs-module-lexer` due to their
inclusion in the `deps_files` entry in
[node.gyp](https://github.com/nodejs/node/blob/master/node.gyp).
[node.gyp](https://github.com/nodejs/node/blob/main/node.gyp).
The two different versions of lexer.js are maintained in the
[nodejs/cjs-module-lexer][] project.

2
doc/contributing/maintaining-npm.md
View File

@ -41,7 +41,7 @@ Note: please ensure you are only making the updates that are changed by npm.
## Step 4: Apply whitespace fix
```console
$ git rebase --whitespace=fix master
$ git rebase --whitespace=fix main
```
## Step 5: Test the build

2
doc/contributing/maintaining-openssl.md
View File

@ -5,7 +5,7 @@ This document describes how to update `deps/openssl/`.
If you need to provide updates across all active release lines you will
currently need to generate four PRs as follows:
* a PR for master which is generated following the instructions
* a PR for `main` which is generated following the instructions
below for OpenSSL 3.x.x.
* a PR for 16.x following the instructions in the v16.x-staging version
of this guide.

10
doc/contributing/maintaining-web-assembly.md
View File

@ -2,7 +2,7 @@
Support for [WebAssembly](https://webassembly.org/)
has been identified as one of the
[top technical priorities](https://github.com/nodejs/node/blob/master/doc/contributing/technical-priorities.md#webassembly)
[top technical priorities](https://github.com/nodejs/node/blob/main/doc/contributing/technical-priorities.md#webassembly)
for the future success of Node.js.
This document provides an overview of our high-level strategy for
@ -76,7 +76,7 @@ The Node.js WASI implementation is maintained in the
[uvwasi](https://github.com/nodejs/uvwasi) repository in the
Node.js GitHub organization. As needed, an updated copy
is vendored into the Node.js deps in
[deps/uvwasi](https://github.com/nodejs/node/tree/master/deps/uvwasi).
[deps/uvwasi](https://github.com/nodejs/node/tree/main/deps/uvwasi).
To update the copy of uvwasi in the Node.js deps:
@ -92,6 +92,6 @@ The documentation for this API is in
The implementation of the bindings and the public API is in:
* [src/node\_wasi.h](https://github.com/nodejs/node/blob/master/src/node_wasi.h)
* [src/node\_wasi.cc](https://github.com/nodejs/node/blob/master/src/node_wasi.cc)
* [lib/wasi.js](https://github.com/nodejs/node/blob/master/lib/wasi.js)
* [src/node\_wasi.h](https://github.com/nodejs/node/blob/main/src/node_wasi.h)
* [src/node\_wasi.cc](https://github.com/nodejs/node/blob/main/src/node_wasi.cc)
* [lib/wasi.js](https://github.com/nodejs/node/blob/main/lib/wasi.js)

12
doc/contributing/writing-and-running-benchmarks.md
View File

@ -256,17 +256,17 @@ As an example on how to check for a possible performance improvement, the
an example. This pull request _claims_ to improve the performance of the
`node:string_decoder` module.
First build two versions of Node.js, one from the master branch (here called
`./node-master`) and another with the pull request applied (here called
First build two versions of Node.js, one from the `main` branch (here called
`./node-main`) and another with the pull request applied (here called
`./node-pr-5134`).
To run multiple compiled versions in parallel you need to copy the output of the
build: `cp ./out/Release/node ./node-master`. Check out the following example:
build: `cp ./out/Release/node ./node-main`. Check out the following example:
```console
$ git checkout master
$ git checkout main
$ ./configure && make -j4
$ cp ./out/Release/node ./node-master
$ cp ./out/Release/node ./node-main
$ git checkout pr-5134
$ ./configure && make -j4
@ -276,7 +276,7 @@ $ cp ./out/Release/node ./node-pr-5134
The `compare.js` tool will then produce a csv file with the benchmark results.
```console
$ node benchmark/compare.js --old ./node-master --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
$ node benchmark/compare.js --old ./node-main --new ./node-pr-5134 string_decoder > compare-pr-5134.csv
```
_Tips: there are some useful options of `benchmark/compare.js`. For example,

2
doc/contributing/writing-tests.md
View File

@ -469,7 +469,7 @@ will depend on what is being tested if this is required or not.
To generate a test coverage report, see the
[Test Coverage section of the Building guide][].
Nightly coverage reports for the Node.js master branch are available at
Nightly coverage reports for the Node.js `main` branch are available at
<https://coverage.nodejs.org/>.
[ASCII]: https://man7.org/linux/man-pages/man7/ascii.7.html