From 41ac2cc49ae05e6a4801ae726da25334fd1061e5 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Mon, 29 Jun 2026 17:15:31 +0100 Subject: [PATCH 01/14] doc: various updates to releases.md - Clarify permissions needed to be able to prepare a release - Add CitGM to the "relevant jenkins jobs" section - Clarify GPG key creation process and algorithms - Also suggest that GPG keys can be published to ubuntu's keyservers - Clarify that signed commits on release branches are required - Add note about branch-diff using significant github API credits - Explicit comment on each section which can be skipped with automation Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 114 +++++++++++++++++++++++++++-------- 1 file changed, 88 insertions(+), 26 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 1f33d8f2771732..ba5eabd050bf2c 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -39,24 +39,40 @@ official release builds for Node.js, hosted on . ## Who can make a release? -Release authorization is given by the Node.js TSC. Once authorized, an -individual must have the following: +Individuals who are Members of the +[backporters team](https://github.com/orgs/nodejs/teams/backporters) can +land things on the staging branches and prepare releases. This is a +prerequisite to being able to prepare releases which is the first step +to becoming a releaser. + +Release authorization is given by the Node.js TSC. This is required to +publish a release after it has been prepared. If you are working on +preparing a release for the first time you can do that and have someone else +who is already onboarded publish the release on your behalf. Once +authorized by the TSC, an individual will be require the following: ### 1. Jenkins release access -There are three relevant Jenkins jobs that should be used for a release flow: +There are four relevant Jenkins jobs that should be used for a release flow: **a.** **Test runs:** **[node-test-pull-request](https://ci.nodejs.org/job/node-test-pull-request/)** is used for a final full-test run to ensure that the current _HEAD_ is stable. -**b.** **Nightly builds:** (optional) +**b.** **CITGM:** +**[citgm-smoker](https://ci.nodejs.org/job/citgm-smoker/)** is used to run +the citgm tool which tests a build of node.js against a defined set of +community modules. This is used during a release process to ensure that +none of the commonly used modules which are tested by CITGM show functional +regressions with the new Node.js version which could impact users. + +**c.** **Nightly builds:** (optional) **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** can be used to create a nightly release for the current _HEAD_ if public test releases are required. Builds triggered with this job are published straight to and are available for public download. -**c.** **Release builds:** +**d.** **Release builds:** **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** does all of the work to build all required release assets. Promotion of the release files is a manual step once they are ready (see below). @@ -66,8 +82,8 @@ this access to individuals authorized by the TSC. ### 2. \ access -The _dist_ user on nodejs.org controls the assets available in -. is an alias for +The _dist_ user on the `nodejs.org` host controls the assets available in +. is an alias for . The Jenkins release build workers upload their artifacts to the web server as @@ -90,6 +106,12 @@ responsible for that release. In order to be able to verify downloaded binaries, the public should be able to check that the `SHASUMS256.txt` file has been signed by someone who has been authorized to create a release. +If you do not currently have a key then you should create one with a +suitable strength with `gpg --full-generate-key`. The default options +(currently "ECC sign and encrypt" and "Curve 25519") are good choices and +consistent with the +[ssh key recommendations in the GOVERNANCE.md file](https://github.com/nodejs/Release/blob/main/GOVERNANCE.md#ssh-key-guidance). + The public keys should be fetchable from a known third-party keyserver. The OpenPGP keyserver at is recommended. Use the [submission](https://keys.openpgp.org/upload) form to submit @@ -108,11 +130,23 @@ gpg --keyserver hkps://keys.openpgp.org --recv-keys The key you use may be a child/subkey of an existing key. +If you wish to also upload your key to the commonly used Ubuntu keyservers +you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys +` and check it by switching the server name in the +`--recv-keys` operation list above to the Ubuntu keyserver. + Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the Node.js GitHub README.md file. -> It is recommended to sign all commits under the Node.js repository. -> Run: `git config commit.gpgsign true` inside the `node` folder. +> All commits to branches in `nodejs/node` other than `main` MUST be signed +> otherwise pushing to those branches will fail +> Run: `git config commit.gpgsign true` inside the `node` folder or use the +> `-S` flag on your git operations (The examples in this document will +> include `-S` expliticlty) + +Note that while GitHub allows signing individual commits using an ssh key, +that is not covered here as this will not allow you to sign releases, so you +will need to set up a GPG signing key in GitHub. ## How to create a release @@ -123,7 +157,7 @@ Notes: * Version strings are listed below as _"vx.y.z"_ or _"x.y.z"_. Substitute for the release version. * Examples will use the fictional release version `1.2.3`. -* When preparing a security release, follow the security steps in the details +* *When preparing a security release*, follow the security steps in the details sections. ### 0. Pre-release steps @@ -136,13 +170,6 @@ and the release blog post is available on the project website. Build can be contacted best by opening up an issue on the [Build issue 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 `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. - ### 1. Update the staging branch Checkout the staging branch locally. @@ -174,11 +201,11 @@ 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`. -You can add the `Backport-PR-URL` metadata by using `--backport` with -`git node land` +You can add the `Backport-PR-URL` metadata automatically when landing by +using `--backport` with `git node land`: ```bash -git node land --backport $PR-NUMBER +git node land --backport $PR-NUMBER -S ``` To determine the relevant commits, use @@ -189,16 +216,34 @@ metadata, as well as the GitHub labels such as `semver-minor` and omitted from a commit, the commit will show up because it's unsure if it's a duplicate or not. +Note that a branch-diff run can use a lot of credits and users are +[limited by default to 5000 per hour](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2026-03-10). +It is not unusual for a run of branch-diff to +use around 1000 of these. For this reason it is recommended that when you +run branch-diff you redirect the output to a file and then process it. You +can check your current usage with `gh rate_limit` if you have the GitHub CLI +installed and configured, or using the curl command from +[this link](https://docs.github.com/en/rest/rate-limit/rate-limit?apiVersion=2026-03-10) +with authentication e.g. + +``` +curl -H "Authorization: token $YOURGITHUBTOKEN" -X GET https://api.github.com/rate_limit +``` + For a list of commits that could be landed in a minor release on v1.x: ```bash N=1 sh -c 'branch-diff v$N.x-staging upstream/main --exclude-label=semver-major,dont-land-on-v$N.x,backport-requested-v$N.x,backport-blocked-v$N.x,backport-open-v$N.x,backported-to-v$N.x --filter-release --format=simple' ``` -If the target branch is an LTS line, you should also exclude the `baking-for-lts`: +If the target branch is an LTS line, you should also exclude the +`baking-for-lts` and use a version other than `main` (usually a tag of the +next actively supported version which has been available for at least two +weeks). In this example we use v26.5.0 as the version to compare with if +we are preparing a release for v24: ```bash -N=1 sh -c 'branch-diff v$N.x-staging upstream/main --exclude-label=semver-major,dont-land-on-v$N.x,backport-requested-v$N.x,backport-blocked-v$N.x,backport-open-v$N.x,backported-to-v$N.x,baking-for-lts --filter-release --format=simple' +N=24 sh -c 'branch-diff v$N.x-staging v26.5.0 --exclude-label=semver-major,dont-land-on-v$N.x,backport-requested-v$N.x,backport-blocked-v$N.x,backport-open-v$N.x,backported-to-v$N.x,baking-for-lts --filter-release --format=simple' ``` Previously released commits and version bumps do not need to be @@ -216,6 +261,11 @@ Carefully review the list of commits: When you are ready to cherry-pick commits, you can automate with the following command. +Since this is slightly different from the previous branch-diff output - it +contains only the commit shas and in revert order - you may wish to save +this before piping it directly to `git cherry-pick` in case it does not go +cleanly. + ```bash N=1 sh -c 'branch-diff v$N.x-staging upstream/main --exclude-label=semver-major,dont-land-on-v$N.x,backport-requested-v$N.x,backport-blocked-v$N.x,backport-open-v$N.x,backported-to-v$N.x --filter-release --format=sha --reverse' | xargs git cherry-pick -S ``` @@ -351,6 +401,8 @@ This will ensure they are included in the "Notable Changes" section of the CHANG ### 3. Update `src/node_version.h` +_(This step will be done automatically if you are using `create-release-proposal` or `git node release --prepare`)_ + Set the version for the proposed release using the following macros, which are already defined in `src/node_version.h`: @@ -369,6 +421,8 @@ be produced with a version string that does not have a trailing pre-release tag: ### 4. Update the changelog +_(This step will be done automatically if you are using `create-release-proposal` or `git node release --prepare`)_ + #### Step 1: Collect the formatted list of changes Collect a formatted list of commits since the last release. Use @@ -485,7 +539,8 @@ are formatted correctly. If this release includes new APIs then it is necessary to document that they were first added in this version. The relevant commits should already include `REPLACEME` tags (see [Writing Documentation](./api-documentation.md#writing-documentation)). -Check for these tags with +Check for these tags with either `sed` or `perl` as follows, ensuring the +`$VERSION` is prefixed with a `v`. ```bash grep REPLACEME doc/api/*.md @@ -509,8 +564,6 @@ or perl -pi -e "s/REPLACEME/$VERSION/g" doc/api/*.md ``` -`$VERSION` should be prefixed with a `v`. - If this release includes any new deprecations it is necessary to ensure that those are assigned a proper static deprecation code. These are listed in the docs (see `doc/api/deprecations.md`) and in the source as `DEP00XX`. The code @@ -520,6 +573,8 @@ run. ### 5. Create release commit +_(This step will be done automatically if you are using `create-release-proposal` or `git node release --prepare`)_ + The `CHANGELOG.md`, `doc/changelogs/CHANGELOG_Vx.md`, `src/node_version.h`, and `REPLACEME` changes should be the final commit that will be tagged for the release. When committing these to git, use the following message format: @@ -561,6 +616,8 @@ Otherwise, you will leak the commits before the security release. ### 6. Propose release on GitHub +_(This step will be done automatically if you are using `create-release-proposal` or `git node release --prepare`)_ + Push the release branch to `nodejs/node`, not to your own fork. This allows release branches to more easily be passed between members of the release team if necessary. @@ -612,13 +669,18 @@ purpose. Run it once with the base `vx.x` branch as a reference and with the proposal branch to check if new regressions could be introduced in the ecosystem. -Use `ncu-ci` to compare `vx.x` run (10) and proposal branch (11) +Use `ncu-ci` with the two build numbers from the `citgm-smoker` job to +compare the base `vx.x` run (10) and the new proposal branch (11). ```bash npm i -g @node-core/utils ncu-ci citgm 10 11 ``` +Note that a number of the modules tested by CITGM are not completely +reliable so differences shown by the comparison are not immediately cause +for concern. +
Security release From 3ac60ef75dab912d9b9c8f9cfea3f2ac7f940b12 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Mon, 29 Jun 2026 17:55:00 +0100 Subject: [PATCH 02/14] Placate linter Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index ba5eabd050bf2c..906d7beec8eb53 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -59,11 +59,11 @@ There are four relevant Jenkins jobs that should be used for a release flow: **[node-test-pull-request](https://ci.nodejs.org/job/node-test-pull-request/)** is used for a final full-test run to ensure that the current _HEAD_ is stable. -**b.** **CITGM:** +**b.** **CitGM:** **[citgm-smoker](https://ci.nodejs.org/job/citgm-smoker/)** is used to run -the citgm tool which tests a build of node.js against a defined set of +the CitGM tool which tests a build of Node.js against a defined set of community modules. This is used during a release process to ensure that -none of the commonly used modules which are tested by CITGM show functional +none of the commonly used modules which are tested by CitGM show functional regressions with the new Node.js version which could impact users. **c.** **Nightly builds:** (optional) @@ -131,8 +131,7 @@ gpg --keyserver hkps://keys.openpgp.org --recv-keys The key you use may be a child/subkey of an existing key. If you wish to also upload your key to the commonly used Ubuntu keyservers -you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys -` and check it by switching the server name in the +you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys ` and check it by switching the server name in the `--recv-keys` operation list above to the Ubuntu keyserver. Additionally, full GPG key fingerprints for individuals authorized to release @@ -144,7 +143,7 @@ should be listed in the Node.js GitHub README.md file. > `-S` flag on your git operations (The examples in this document will > include `-S` expliticlty) -Note that while GitHub allows signing individual commits using an ssh key, +While GitHub allows signing individual commits using an ssh key, that is not covered here as this will not allow you to sign releases, so you will need to set up a GPG signing key in GitHub. @@ -157,7 +156,7 @@ Notes: * Version strings are listed below as _"vx.y.z"_ or _"x.y.z"_. Substitute for the release version. * Examples will use the fictional release version `1.2.3`. -* *When preparing a security release*, follow the security steps in the details +* _When preparing a security release_, follow the security steps in the details sections. ### 0. Pre-release steps @@ -216,7 +215,7 @@ metadata, as well as the GitHub labels such as `semver-minor` and omitted from a commit, the commit will show up because it's unsure if it's a duplicate or not. -Note that a branch-diff run can use a lot of credits and users are +A `branch-diff` run can use a lot of credits and users are [limited by default to 5000 per hour](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2026-03-10). It is not unusual for a run of branch-diff to use around 1000 of these. For this reason it is recommended that when you @@ -226,7 +225,7 @@ installed and configured, or using the curl command from [this link](https://docs.github.com/en/rest/rate-limit/rate-limit?apiVersion=2026-03-10) with authentication e.g. -``` +```bash curl -H "Authorization: token $YOURGITHUBTOKEN" -X GET https://api.github.com/rate_limit ``` @@ -677,7 +676,7 @@ npm i -g @node-core/utils ncu-ci citgm 10 11 ``` -Note that a number of the modules tested by CITGM are not completely +A number of the modules tested by CitGM are not completely reliable so differences shown by the comparison are not immediately cause for concern. From 72726316eb346cbfeb9878bb48058a2510f28e37 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Mon, 29 Jun 2026 18:22:06 +0100 Subject: [PATCH 03/14] placate linter Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 906d7beec8eb53..d550b04a029d2e 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -131,7 +131,8 @@ gpg --keyserver hkps://keys.openpgp.org --recv-keys The key you use may be a child/subkey of an existing key. If you wish to also upload your key to the commonly used Ubuntu keyservers -you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys ` and check it by switching the server name in the +you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys +` and check it by switching the server name in the `--recv-keys` operation list above to the Ubuntu keyserver. Additionally, full GPG key fingerprints for individuals authorized to release From 939cf2474760624ce51771faa165ae73b439f1c4 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:23:29 +0100 Subject: [PATCH 04/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index d550b04a029d2e..533a32a907ec96 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -139,7 +139,7 @@ Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the Node.js GitHub README.md file. > All commits to branches in `nodejs/node` other than `main` MUST be signed -> otherwise pushing to those branches will fail +> otherwise pushing to those branches will be rejected by GitHub. > Run: `git config commit.gpgsign true` inside the `node` folder or use the > `-S` flag on your git operations (The examples in this document will > include `-S` expliticlty) From 4c252d192745a9fca79f1554cae6a23122416f79 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:26:43 +0100 Subject: [PATCH 05/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 533a32a907ec96..884d0e8f539011 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -157,7 +157,7 @@ Notes: * Version strings are listed below as _"vx.y.z"_ or _"x.y.z"_. Substitute for the release version. * Examples will use the fictional release version `1.2.3`. -* _When preparing a security release_, follow the security steps in the details +* When preparing a _security release_, follow the security steps in the details sections. ### 0. Pre-release steps From 02035008bfe3addb13abfc31cde823898bddfc37 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:28:01 +0100 Subject: [PATCH 06/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 884d0e8f539011..f830e2fb0d3908 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -138,7 +138,7 @@ you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the Node.js GitHub README.md file. -> All commits to branches in `nodejs/node` other than `main` MUST be signed +> All commits to branches in `nodejs/node` other than `main` and `actions/*` MUST be signed > otherwise pushing to those branches will be rejected by GitHub. > Run: `git config commit.gpgsign true` inside the `node` folder or use the > `-S` flag on your git operations (The examples in this document will From 337b900182b956a4d9aa0d8c9db20a96c4cb18de Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Mon, 29 Jun 2026 18:33:04 +0100 Subject: [PATCH 07/14] doc: standardise -S at the start of "git node" commands Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index f830e2fb0d3908..f03847a29d7fc3 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -205,7 +205,7 @@ You can add the `Backport-PR-URL` metadata automatically when landing by using `--backport` with `git node land`: ```bash -git node land --backport $PR-NUMBER -S +git node land -S --backport $PR-NUMBER ``` To determine the relevant commits, use @@ -806,7 +806,7 @@ Once you have produced builds that you're happy with you can either run `git node release --promote`: ```bash -git node release --promote https://github.com/nodejs/node/pull/XXXX -S +git node release -S --promote https://github.com/nodejs/node/pull/XXXX ``` to automate the remaining steps until step 16 or you can perform it manually @@ -822,11 +822,10 @@ fetch the proposal from using the `--fetch-from` flag. When promoting several releases, you can pass multiple URLs: ```bash -git node release --promote \ +git node release -S --promote \ --fetch-from git@github.com:nodejs-private/node-private.git \ https://github.com/nodejs-private/node-private/pull/XXXX \ - https://github.com/nodejs-private/node-private/pull/XXXX \ - -S + https://github.com/nodejs-private/node-private/pull/XXXX ```
From 622964808f26746b1f1fbbe8f369789daa356f15 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:39:19 +0100 Subject: [PATCH 08/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index f03847a29d7fc3..721f3c80d258fb 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -237,10 +237,8 @@ N=1 sh -c 'branch-diff v$N.x-staging upstream/main --exclude-label=semver-major, ``` If the target branch is an LTS line, you should also exclude the -`baking-for-lts` and use a version other than `main` (usually a tag of the -next actively supported version which has been available for at least two -weeks). In this example we use v26.5.0 as the version to compare with if -we are preparing a release for v24: +`baking-for-lts` and use a Current version released at least two weeks before the expected release date. +In this example we use 25.5.0 as the base version to prepare a release for Node.js 24: ```bash N=24 sh -c 'branch-diff v$N.x-staging v26.5.0 --exclude-label=semver-major,dont-land-on-v$N.x,backport-requested-v$N.x,backport-blocked-v$N.x,backport-open-v$N.x,backported-to-v$N.x,baking-for-lts --filter-release --format=simple' From 1aa7f8354d107b525b742d1ff20643da700db157 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:42:02 +0100 Subject: [PATCH 09/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 721f3c80d258fb..7dc9e9405c9ff7 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -45,10 +45,10 @@ land things on the staging branches and prepare releases. This is a prerequisite to being able to prepare releases which is the first step to becoming a releaser. -Release authorization is given by the Node.js TSC. This is required to -publish a release after it has been prepared. If you are working on +Release authorization is given by the Node.js TSC. This is required to +promote a release after it has been prepared. If you are working on preparing a release for the first time you can do that and have someone else -who is already onboarded publish the release on your behalf. Once +who is already onboarded promote the release on your behalf. Once authorized by the TSC, an individual will be require the following: ### 1. Jenkins release access From 6227db30fbacd53037ac36c4aa1edc3bb809cdb8 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Mon, 29 Jun 2026 18:43:30 +0100 Subject: [PATCH 10/14] doc: standardise -S at the start of "git node" commands Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 7dc9e9405c9ff7..de407cfb54a5fe 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -537,8 +537,8 @@ are formatted correctly. If this release includes new APIs then it is necessary to document that they were first added in this version. The relevant commits should already include `REPLACEME` tags (see [Writing Documentation](./api-documentation.md#writing-documentation)). -Check for these tags with either `sed` or `perl` as follows, ensuring the -`$VERSION` is prefixed with a `v`. +Check for the presence of these tags and then update them either `sed` or +`perl`. Ensure that `$VERSION` is prefixed with a `v`: ```bash grep REPLACEME doc/api/*.md From f3f62f4a3eac7dc0fd583b3f4070f3f719919705 Mon Sep 17 00:00:00 2001 From: Stewart X Addison <6487691+sxa@users.noreply.github.com> Date: Mon, 29 Jun 2026 18:48:10 +0100 Subject: [PATCH 11/14] Update doc/contributing/releases.md Co-authored-by: Antoine du Hamel --- doc/contributing/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index de407cfb54a5fe..10e8e75cc3dea2 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -260,7 +260,7 @@ When you are ready to cherry-pick commits, you can automate with the following command. Since this is slightly different from the previous branch-diff output - it -contains only the commit shas and in revert order - you may wish to save +contains only the commit SHAs and in revert order - you may wish to save this before piping it directly to `git cherry-pick` in case it does not go cleanly. From e76dc78f7e524aa5c74555408fe96e69dcbcabf0 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Tue, 30 Jun 2026 10:02:18 +0100 Subject: [PATCH 12/14] Reformating to placate linter Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 10e8e75cc3dea2..b23ce4268dab76 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -131,9 +131,14 @@ gpg --keyserver hkps://keys.openpgp.org --recv-keys The key you use may be a child/subkey of an existing key. If you wish to also upload your key to the commonly used Ubuntu keyservers -you can do so with `gpg --keyserver keyserver.ubuntu.com --send-keys -` and check it by switching the server name in the -`--recv-keys` operation list above to the Ubuntu keyserver. +you can do so with + +```bash +gpg --keyserver keyserver.ubuntu.com --send-keys +``` + +and check it by switching the server name in the `--recv-keys` operation +list above to the Ubuntu keyserver. Additionally, full GPG key fingerprints for individuals authorized to release should be listed in the Node.js GitHub README.md file. From 0402d062fcc1f37ace816f7b54741beb0d828169 Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Tue, 30 Jun 2026 10:05:49 +0100 Subject: [PATCH 13/14] Rewording sed/perl commands for REPLACEME tags Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index b23ce4268dab76..48feece6fc63a1 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -542,14 +542,15 @@ are formatted correctly. If this release includes new APIs then it is necessary to document that they were first added in this version. The relevant commits should already include `REPLACEME` tags (see [Writing Documentation](./api-documentation.md#writing-documentation)). -Check for the presence of these tags and then update them either `sed` or -`perl`. Ensure that `$VERSION` is prefixed with a `v`: ```bash grep REPLACEME doc/api/*.md ``` -and substitute this node version with +The above command will check for the presence of the tags and show you which +files need to be updated. You can then perform the replacements with one of +the following commands using either `sed` or `perl`. In these examples +`$VERSION` must be prefixed with a `v`: ```bash sed -i "s/REPLACEME/$VERSION/g" doc/api/*.md From 7099b3d9c798f9f295725a0024a2ff721d20f0cd Mon Sep 17 00:00:00 2001 From: Stewart X Addison Date: Tue, 30 Jun 2026 10:26:29 +0100 Subject: [PATCH 14/14] remove obsolete "CI lockdown procedure" footnote Signed-off-by: Stewart X Addison --- doc/contributing/releases.md | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/contributing/releases.md b/doc/contributing/releases.md index 48feece6fc63a1..cb47959cabd5c4 100644 --- a/doc/contributing/releases.md +++ b/doc/contributing/releases.md @@ -1559,7 +1559,6 @@ Typical resolution: sign the release again. ``` [Build issue tracker]: https://github.com/nodejs/build/issues/new -[CI lockdown procedure]: https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#restricting-access-for-security-releases [Node.js Snap management repository]: https://github.com/nodejs/snap [Snap]: https://snapcraft.io/node [`create-release-post.yml`]: https://github.com/nodejs/nodejs.org/actions/workflows/create-release-post.yml