From 7bf50bc26aa01308d06ffd6bd75864c29486fa0b Mon Sep 17 00:00:00 2001 From: Luigi Pinca Date: Thu, 16 Jun 2022 15:10:56 +0200 Subject: [PATCH] doc: update main branch name in doc/contributing/* MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Refs: https://github.com/nodejs/node/issues/33864 PR-URL: https://github.com/nodejs/node/pull/43438 Reviewed-By: Richard Lau Reviewed-By: Antoine du Hamel Reviewed-By: Tobias Nießen Reviewed-By: Danielle Adams Reviewed-By: Gireesh Punathil Reviewed-By: Darshan Sen Reviewed-By: LiviaMedeiros Reviewed-By: Rich Trott --- .../backporting-to-release-lines.md | 2 +- doc/contributing/collaborator-guide.md | 44 +++++++++---------- doc/contributing/commit-queue.md | 4 +- .../diagnostic-tooling-support-tiers.md | 2 +- doc/contributing/maintaining-V8.md | 12 ++--- .../maintaining-cjs-module-lexer.md | 2 +- doc/contributing/maintaining-npm.md | 2 +- doc/contributing/maintaining-openssl.md | 2 +- doc/contributing/maintaining-web-assembly.md | 10 ++--- .../writing-and-running-benchmarks.md | 12 ++--- doc/contributing/writing-tests.md | 2 +- 11 files changed, 47 insertions(+), 47 deletions(-) diff --git a/doc/contributing/backporting-to-release-lines.md b/doc/contributing/backporting-to-release-lines.md index 68b723c5599..eebb5a85961 100644 --- a/doc/contributing/backporting-to-release-lines.md +++ b/doc/contributing/backporting-to-release-lines.md @@ -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 diff --git a/doc/contributing/collaborator-guide.md b/doc/contributing/collaborator-guide.md index 5de13b79236..31313b1e2ad 100644 --- a/doc/contributing/collaborator-guide.md +++ b/doc/contributing/collaborator-guide.md @@ -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 ``" 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 diff --git a/doc/contributing/commit-queue.md b/doc/contributing/commit-queue.md index 92047ade50a..4730d0889e9 100644 --- a/doc/contributing/commit-queue.md +++ b/doc/contributing/commit-queue.md @@ -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. diff --git a/doc/contributing/diagnostic-tooling-support-tiers.md b/doc/contributing/diagnostic-tooling-support-tiers.md index 7615faebb2e..597e46986f8 100644 --- a/doc/contributing/diagnostic-tooling-support-tiers.md +++ b/doc/contributing/diagnostic-tooling-support-tiers.md @@ -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: diff --git a/doc/contributing/maintaining-V8.md b/doc/contributing/maintaining-V8.md index 466e19b38bf..18f63f9cdca 100644 --- a/doc/contributing/maintaining-V8.md +++ b/doc/contributing/maintaining-V8.md @@ -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: diff --git a/doc/contributing/maintaining-cjs-module-lexer.md b/doc/contributing/maintaining-cjs-module-lexer.md index d049702ed65..43dcfe0d231 100644 --- a/doc/contributing/maintaining-cjs-module-lexer.md +++ b/doc/contributing/maintaining-cjs-module-lexer.md @@ -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. diff --git a/doc/contributing/maintaining-npm.md b/doc/contributing/maintaining-npm.md index 5536fd513f8..a1b6e170dd1 100644 --- a/doc/contributing/maintaining-npm.md +++ b/doc/contributing/maintaining-npm.md @@ -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 diff --git a/doc/contributing/maintaining-openssl.md b/doc/contributing/maintaining-openssl.md index 9228b9c6bb1..feef99753b2 100644 --- a/doc/contributing/maintaining-openssl.md +++ b/doc/contributing/maintaining-openssl.md @@ -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. diff --git a/doc/contributing/maintaining-web-assembly.md b/doc/contributing/maintaining-web-assembly.md index 037d296232d..c5df8f7c058 100644 --- a/doc/contributing/maintaining-web-assembly.md +++ b/doc/contributing/maintaining-web-assembly.md @@ -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) diff --git a/doc/contributing/writing-and-running-benchmarks.md b/doc/contributing/writing-and-running-benchmarks.md index bab0cc1c2fa..99325d87692 100644 --- a/doc/contributing/writing-and-running-benchmarks.md +++ b/doc/contributing/writing-and-running-benchmarks.md @@ -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, diff --git a/doc/contributing/writing-tests.md b/doc/contributing/writing-tests.md index c24526f0139..cc75191d320 100644 --- a/doc/contributing/writing-tests.md +++ b/doc/contributing/writing-tests.md @@ -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 . [ASCII]: https://man7.org/linux/man-pages/man7/ascii.7.html