1 # Node.js release process
3 This document describes the technical aspects of the Node.js release process.
5 Technical Steering Committee (TSC) to create, promote, and sign
6 official release builds for Node.js, hosted on <https://nodejs.org/>.
10 * [Who can make a release?](#who-can-make-a-release)
11   * [1. Jenkins release access](#1-jenkins-release-access)
12   * [2. \<nodejs.org> access](#2-nodejsorg-access)
13   * [3. A publicly listed GPG key](#3-a-publicly-listed-gpg-key)
14 * [How to create a release](#how-to-create-a-release)
15   * [0. Pre-release steps](#0-pre-release-steps)
16   * [1. Update the staging branch](#1-update-the-staging-branch)
17   * [2. Create a new branch for the release](#2-create-a-new-branch-for-the-release)
18   * [3. Update `src/node_version.h`](#3-update-srcnode_versionh)
19   * [4. Update the changelog](#4-update-the-changelog)
20   * [5. Create release commit](#5-create-release-commit)
21   * [6. Propose release on GitHub](#6-propose-release-on-github)
22   * [7. Ensure that the release branch is stable](#7-ensure-that-the-release-branch-is-stable)
23     * [7.1 Updating the release _(optional)_](#7-1-updating-the-release-optional)
24   * [8. Produce a nightly build _(optional)_](#8-produce-a-nightly-build-optional)
25   * [9. Produce release builds](#9-produce-release-builds)
26   * [10. Test the build](#10-test-the-build)
27   * [11. Tag and sign the release commit](#11-tag-and-sign-the-release-commit)
28   * [12. Set up for the next release](#12-set-up-for-the-next-release)
29   * [13. Cherry-pick the release commit to `main`](#13-cherry-pick-the-release-commit-to-main)
30   * [14. Push the release tag](#14-push-the-release-tag)
31   * [15. Promote and sign the release builds](#15-promote-and-sign-the-release-builds)
32   * [16. Check the release](#16-check-the-release)
33   * [17. Create a blog post](#17-create-a-blog-post)
34   * [18. Create the release on GitHub](#18-create-the-release-on-github)
35   * [19. Cleanup](#19-cleanup)
36   * [20. Announce](#20-announce)
37   * [21. Celebrate](#21-celebrate)
38 * [LTS releases](#lts-releases)
39 * [Major releases](#major-releases)
41 ## Who can make a release?
43 Release authorization is given by the Node.js TSC. Once authorized, an
46 ### 1. Jenkins release access  argument
48 There are three relevant Jenkins jobs that should be used for a release flow:
51 **[node-test-pull-request](https://ci.nodejs.org/job/node-test-pull-request/)**
52 is used for a final full-test run to ensure that the current _HEAD_ is stable.
55 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** can be used
56 to create a nightly release for the current _HEAD_ if public test releases are
60 **c.** **Release builds:**
61 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** does all of
62 the work to build all required release assets. Promotion of the release files is
72 <https://nodejs.org/download/release/>.
74 The Jenkins release build workers upload their artifacts to the web server as
81 Release builds require manual promotion by an individual with SSH access to the
86 ### 3. A publicly-listed GPG key
90 responsible for that release. In order to be able to verify downloaded binaries,
92 signed by someone who has been authorized to create a release.
94 The GPG keys should be fetchable from a known third-party keyserver. The SKS
95 Keyservers at <https://sks-keyservers.net> are recommended. Use the
97 do an ASCII-armored export of your key first:
100 $ gpg --armor --export email@server.com > ~/nodekey.asc
106 $ gpg --keyserver pool.sks-keyservers.net --recv-keys <FINGERPRINT>
111 Additionally, full GPG key fingerprints for individuals authorized to release
114 ## How to create a release
118 * Dates listed below as _"YYYY-MM-DD"_ should be the date of the release **as
119   UTC**. Use `date -u +'%Y-%m-%d'` to find out what this is.
121   the release version.
122 * Examples will use the fictional release version `1.2.3`.
123 * When preparing a security release, follow the security steps in the details
126 ### 0. Pre-release steps
128 Before preparing a Node.js release, the Build Working Group must be notified at
129 least one business day in advance of the expected release. Coordinating with
130 Build is essential to make sure that the CI works, release files are published,
131 and the release blog post is available on the project website.
136 When preparing a security release, contact Build at least two weekdays in
137 advance of the expected release. To ensure that the security patch(es) can be
138 properly tested, run a `node-test-pull-request` job against the `main` branch
139 of the `nodejs-private/node-private` repository a day or so before the
149 $ git checkout v1.x-staging
150 $ git reset --hard upstream/v1.x-staging
156 … label](https://github.com/nodejs/node/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3Av8.x).
166 When landing the PR add the `Backport-PR-URL:` line to each commit. Close the
168 `backport-requested-vN.x` to `backported-to-vN.x`.
170 You can add the `Backport-PR-URL` metadata by using `--backport` with
174 $ git node land --backport $PR-NUMBER
178 [`branch-diff`](https://github.com/nodejs/branch-diff). The tool is available on
180 metadata, as well as the GitHub labels such as `semver-minor` and
181 `semver-major`. One drawback is that when the `PR-URL` metadata is accidentally
185 For a list of commits that could be landed in a patch release on v1.x:
188 …-diff v1.x-staging main --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-reque…
192 cherry-picked.
196 * Checking for errors (incorrect `PR-URL`)
197 * Checking semver status - Commits labeled as `semver-minor` or `semver-major`
198   should only be cherry-picked when appropriate for the type of release being
201   `baking-for-lts` tag.
203 When you are ready to cherry-pick commits, you can automate with the following
204 command. (For semver-minor releases, make sure to remove the `semver-minor` tag
205 from `exclude-label`.)
208 …-diff v1.x-staging main --exclude-label=semver-major,semver-minor,dont-land-on-v1.x,backport-reque…
211 When cherry-picking commits, if there are simple conflicts you can resolve
212 them. Otherwise, add the `backport-requested-vN.x` label to the original PR
214 backport PR. You can refer the owner of the PR to the "[Backporting to Release
215 Lines](https://github.com/nodejs/node/blob/HEAD/doc/contributing/backporting-to-release-lines.md)" …
217 If commits were cherry-picked in this step, check that the test still pass.
223 Then, push to the staging branch to keep it up-to-date.
226 $ git push upstream v1.x-staging
230 <summary>Security release</summary>
232 Security releases with private patches need to be prepared in the `nodejs-private`
235 Add the `nodejs-private` remote:
238 $ git remote add private git@github.com:nodejs-private/node-private.git
242 As there may already be commits on the `vN.x-staging` branch, it is preferable
243 to checkout the `vN.x` branch and build up the release directly in a proposal
248 $ git reset --hard upstream/vN.x
251 The list of patches to include should be listed in the "Next Security Release"
252 issue in `nodejs-private`. Ask the security release steward if you're unsure.
254 The `git node land` tool does not work with the `nodejs-private`
255 organization. To land a PR in Node.js private, use `git cherry-pick` to apply
257 metadata (`PR-URL`, `Reviewed-by`, etc.) by amending the commit messages. If
258 known, additionally include `CVE-ID: CVE-XXXX-XXXXX` in the commit metadata.
260 **Note**: Do not run CI on the PRs in `nodejs-private` until CI is locked down.
265 ### 2. Create a new branch for the release  argument
267 ⚠️ At this point, you can either run `git node release --prepare`:
270 $ git node release --prepare x.y.z
278 Create a new branch named `vx.y.z-proposal`, off the corresponding staging
282 $ git checkout -b v1.2.3-proposal upstream/v1.x-staging
286 <summary>Security release</summary>
288 When performing Security Releases, the `vN.x.x-proposal` branch should be
292 $ git checkout -b v1.2.3-proposal upstream/v1.x
293 git cherry-pick  ...  # cherry-pick nodejs-private PR commits directly into the proposal
300 Set the version for the proposed release using the following macros, which are
310 be produced with a version string that does not have a trailing pre-release tag:
320 Collect a formatted list of commits since the last release. Use
321 [`changelog-maker`](https://github.com/nodejs/changelog-maker) to do this:
324 $ changelog-maker --group --markdown
327 `changelog-maker` counts commits since the last tag and if the last tag
329 `--start-ref` argument:
332 $ changelog-maker --group --markdown --filter-release --start-ref v1.2.2
335 `--filter-release` will remove the release commit from the previous release.
339 There is a separate `CHANGELOG_Vx.md` file for each major Node.js release line.
342 in the release branch (e.g. a release for Node.js v4 would be added to the
351 ## YYYY-MM-DD, Version x.y.z (Release Type), @releaser
360 * Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1"…
363 The release type should be either Current, LTS, or Maintenance, depending on the
364 type of release being produced.
367 commits in the release that have either the `notable-change` or `semver-minor`
368 label. Some `semver-minor` features may be determined by the releaser, or
372 You can use `branch-diff` to get a list of commits with the `notable-change`
376 $ branch-diff upstream/v1.x v1.2.3-proposal --require-label=notable-change --plaintext
383 <summary>Security release</summary>
393 ## YYYY-MM-DD, Version x.y.z (Release Type), @releaser
395 This is a security release.
399 * <CVE Title> (High|Medium|Low)(CVE-XXXX-XXXXX)
404 * Include the full list of commits since the last release here. Do not include "Working on X.Y.Z+1"…
407 … security release changelog entries](https://github.com/nodejs/node/blob/main/doc/changelogs/CHANG…
412 lifted from the "post-release" announcement (should be available in
413 `nodejs-private`). If the CVE is being fixed in multiple release lines, try to
414 coordinate the changelog content between the other release so the descriptions
420 releases in each major release line. A link to the new release needs to be added
421 to it. Follow the existing examples and be sure to add the release to the _top_
422 of the list. The most recent release for each release line is shown in **bold**
424 accordingly by removing the bold styling from the previous release.
426 Run `make format-md` to ensure the `CHANGELOG_Vx.md` and `CHANGELOG.md` files
431 If this release includes new APIs then it is necessary to document that they
443 sed -i "s/REPLACEME/$VERSION/g" doc/api/*.md
449 sed -i "" "s/REPLACEME/$VERSION/g" doc/api/*.md
455 perl -pi -e "s/REPLACEME/$VERSION/g" doc/api/*.md
460 If this release includes any new deprecations it is necessary to ensure that
464 occur when the PR is landed, but a check will be made when the release build is
467 ### 5. Create release commit  argument
471 release. When committing these to git, use the following message format:
474 YYYY-MM-DD, Version x.y.z (Release Type)
478 * Copy the notable changes list here, reformatted for plain-text
480 PR-URL: TBD
484 <summary>Security release</summary>
487 `This is a security release.` to allow the
488 [distribution indexer](https://github.com/nodejs/nodejs-dist-indexer) to
492 YYYY-MM-DD, Version x.y.z (Release Type)
494 This is a security release.
498 * Copy the notable changes list here, reformatted for plain-text
500 PR-URL: TBD
503 **Note**: Ensure to push the proposal branch to the nodejs-private repository.
504 Otherwise, you will leak the commits before the security release.
508 ### 6. Propose release on GitHub  argument
510 Push the release branch to `nodejs/node`, not to your own fork. This allows
511 release branches to more easily be passed between members of the release team if
514 Create a pull request targeting the correct release line. For example, a
515 `v5.3.0-proposal` PR should target `v5.x`, not `main`. Paste the CHANGELOG
533 good place to @-mention the relevant contributors.
535 After opening the PR, update the release commit to include `PR-URL` metadata and
536 force-push the proposal.
539 <summary>Security release</summary>
542 in the `nodejs-private` GitHub repository.
546 ### 7. Ensure that the release branch is stable  argument
548 Run a **[`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)**
550 release.
552 Also run a **[`node-test-commit-v8-linux`](https://ci.nodejs.org/job/node-test-commit-v8-linux/)**
553 test run if the release contains changes to `deps/v8`.
555 Perform some smoke-testing. There is the
556 **[`citgm-smoker`](https://ci.nodejs.org/job/citgm-smoker/)** CI job for this
561 Use `ncu-ci` to compare `vx.x` run (10) and proposal branch (11)
564 $ npm i -g node-core-utils
565 $ ncu-ci citgm 10 11
569 <summary>Security release</summary>
577 #### 7.1 Updating the release _(optional)_
579 Sometimes a release might be deferred to the subsequent day due to several
599 $ git checkout v1.x-staging
600 $ git rebase -i $HASH_PREVIOUS_BAD_COMMIT
602 $ git push -f upstream v1.x-staging
608 $ git checkout v1.2.3-proposal
609 $ git checkout -b v1.2.3-proposal-tmp
610 $ git checkout v1.2.3-proposal
612 $ git reset --hard upstream/v1.x-staging
613 $ git cherry-pick v1.2.3-proposal-tmp
616 Note the `tmp` branch was created just to save the release commit.
618 3. Re-run `changelog-maker` and update the CHANGELOG\_Vx to include the new
623 If there is a reason to produce a test release for the purpose of having others
625 **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** and wait for
634 <summary>Security release</summary>
636 Do not produce a release candidate build.
640 ### 9. Produce release builds  argument
642 Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to
643 produce release artifacts. Enter the commit that you want to build from and
644 select "release" for "disttype".
651 All release workers should achieve "SUCCESS" (and be green, not red). A release
655 You can rebuild the release as many times as you need prior to promoting them if
674 * `process.release` is as expected
680   * Run `make build-addons` before running the tests
684 ./tools/test.py --shell ~/Downloads/node-v18.5.0-linux-x64/bin/node
687 ### 11. Tag and sign the release commit  argument
689 Once you have produced builds that you're happy with, create a new tag. By
690 waiting until this stage to create tags, you can discard a proposed release if
692 tag and pushed it to GitHub, you _**must not**_ delete and re-tag. If you make
693 a mistake after tagging then you'll have to version-bump and start again and
699 git tag -v v6.0.0
703 `2016-04-26 Node.js v6.0.0 (Current) Release`.
705 Install `git-secure-tag` npm module:
708 $ npm install -g git-secure-tag
711 Create a tag using the following command:
714 $ git secure-tag <vx.y.z> <commit-sha> -sm "YYYY-MM-DD Node.js vx.y.z (<release-type>) Release"
717 <sup>The commit-sha is the release commit. You can get it easily by running `git rev-parse HEAD`</s…
719 `release-type` is either "Current" or "LTS". For LTS releases, you should also
720 include the release code name.
723 2019-10-22 Node.js v10.17.0 'Dubnium' (LTS) Release
731 ### 12. Set up for the next release  argument
733 On release proposal branch, edit `src/node_version.h` again and:
743 PR-URL: <full URL to your release proposal PR>
747 version number _and_ a pre-release tag.
749 Merge your release proposal branch into the stable branch that you are releasing
754 $ git merge --ff-only v1.2.3-proposal
756 $ git checkout v1.x-staging
758 $ git push upstream v1.x-staging
762 <summary>Security release</summary>
764 For security releases, you can start merging the release in the `nodejs-private`
769 $ git merge --ff-only v1.2.3-proposal
771 $ git checkout v1.x-staging
773 $ git push private v1.x-staging
781 ### 13. Cherry-pick the release commit to `main`  argument
786 $ git cherry-pick --strategy-option=diff-algorithm=patience v1.x^
794 $ git checkout --ours HEAD -- src/node_version.h
798 <summary>Major version release</summary>
810 $ git commit --amend
818 <sup>Edit `src/node_version.h`, revert `NODE_VERSION_IS_RELEASE` back to `0`, and `git commit --ame…
821 placeholders (that happens when a change previously landed on another release
825 [It's possible that the `cherry-pick` step will end up adding and/or
826 changing unwanted lines](https://github.com/nodejs/Release/issues/771),
828 the cherry-pick step.
830 Then finish cherry-picking and push the commit upstream:
834 $ git diff --staged src doc # read output to validate that changes shows up as expected
835 $ git cherry-pick --continue
836 $ make lint-md && make lint-cpp
840 **Do not** cherry-pick the "Working on vx.y.z" commit to `main`.
843 <summary>Security release</summary>
846 branch (if they apply there). Often, you can just cherry-pick the same commit
847 that landed in the `current` security release which should already have the
855 $ git reset --hard upstream/main
856 $ git cherry-pick ... # apply the patches which apply to main
863 ### 14. Push the release tag  argument
874 remainder of the release steps.
876 ### 15. Promote and sign the release builds  argument
878 **The same individual who signed the release tag must be the one
882 Use `tools/release.sh` to promote and sign the build. Before doing this, you'll
891 The key can be loaded either with `ssh-add`:
895 $ ssh-add ~/.ssh/node_id_rsa
902 $ ./tools/release.sh -i ~/.ssh/node_id_rsa
910 $ NODEJS_RELEASE_HOST=proxy.xyz ./tools/release.sh
913 `tools/release.sh` will perform the following actions when run:
918 to: `gpg --list-secret-keys` to list your keys. If you don't have any keys, it
924 along with the list of artifacts. It will use the `dist-promotable` command on
925 the server to find these. You will be asked, for each promotable release,
926 whether you want to proceed. If there is more than one release to promote (there
927 shouldn't be), be sure to only promote the release you are responsible for.
930 release. The command on the server will be similar to: `dist-promote vx.y.z`.
931 After this step, the release artifacts will be available for download and a
932 `SHASUMS256.txt` file will be present. The release will still be unsigned,
938 …SHASUMS256.txt` file using a command similar to: `gpg --default-key YOURKEY --digest-algo SHA256 -…
943 similar to: `gpg --default-key YOURKEY --digest-algo SHA256 --detach-sign /path/to/SHASUMS256.txt`.
947 **g.** Upload the `SHASUMS256.txt` files back to the server into the release
952 **It is possible to only sign a release by running `./tools/release.sh -s
955 ### 16. Check the release  argument
957 Your release should be available at `https://nodejs.org/dist/vx.y.z/` and
961 at <https://nodejs.org/api/>. Check that the release catalog files are correct
964 ### 17. Create a blog post
968 release. However, the blog post is not yet fully automatic.
970 Create a new blog post by running the [nodejs.org release-post.js script][]:
973 $ node ./scripts/release-post/index.mjs x.y.z
992 * Always use pull-requests on the [nodejs.org repository][]. Be respectful
993   of the website team, but you do not have to wait for PR sign-off. Please
997   Blog: vX.Y.Z release post
999   Refs: <full URL to your release proposal PR>
1006 ### 18. Create the release on GitHub  argument
1008 * Go to the [New release page](https://github.com/nodejs/node/releases/new).
1010 * For release title, copy the title from the changelog.
1013   "Set as the latest release".
1014 * Click on the "Publish release" button.
1022 > v5.8.0 of @nodejs is out: <https://nodejs.org/en/blog/release/v5.8.0/>
1027 24 hour prior notice. If known, please include the date and time the release
1034 <summary>Security release</summary>
1036 Let the security release steward know the releases are available.
1046 ### Marking a release line as LTS
1048 The process of marking a release line as LTS has been automated using
1049 [node-core-utils](https://github.com/nodejs/node-core-utils).
1051 Start by checking out the staging branch for the release line that is going to
1055 $ git checkout v1.x-staging
1058 Next, make sure you have **node-core-utils** installed:
1061 $ npm i -g node-core-utils
1064 Run the prepare LTS release command:
1067 $ git node release --prepare --startLTS
1073 To mark a release line as LTS, the following changes must be made to
1080   for the LTS release.
1085 -#define NODE_MINOR_VERSION 12
1086 -#define NODE_PATCH_VERSION 1
1090 -#define NODE_VERSION_IS_LTS 0
1091 -#define NODE_VERSION_LTS_CODENAME ""
1095 -#define NODE_VERSION_IS_RELEASE 0
1099 The changes must be made as part of a new semver-minor release.
1103 current LTS codename in its release line changelog file.
1105 The `test/parallel/test-process-release.js` file might also need to be updated.
1107 In case you can not run the automated `node-core-utils` command and you are
1113 ### Update release labels
1115 The `lts-watch-vN.x` issue label must be created, with the same color as other
1116 existing labels for that release line, such as `vN.x`.
1118 If the release is transitioning from Active LTS to Maintenance, the
1119 `backport-requested-vN.x` label must be deleted.
1121 ### Add new codename to nodejs-latest-linker
1124 (e.g: <https://nodejs.org/download/release/latest-codename/>) will be available
1125 for the new LTS release line you need to submit a PR to
1126 <https://github.com/nodejs/nodejs-latest-linker> and add a new entry for the
1127 new LTS codename in its `ltsNames` map located in the `./latest-linker.js`
1131 available as part of the LTS release promotion.
1133 ### Update Release repo info
1135 Add the new LTS codename to the release schedule table located in the
1136 `./README.md` file located at the <https://github.com/nodejs/Release>
1142 The process for cutting a new Node.js major release has a number of differences
1143 from cutting a minor or patch release.
1149 * Even-numbered releases are cut in April.
1150 * Odd-numbered releases are cut in October.
1152 Major releases should be targeted for the third Tuesday of the release month.
1154 A major release must not slip beyond the release month. In other words, major
1158 Currently, this call is automated in the `#nodejs-release-private`
1161 The release date for the next major release should be announced immediately
1162 following the current release (e.g. the release date for 13.0.0 should be
1163 announced immediately following the release of 12.0.0).
1165 ### Release branch
1167 Approximately two months before a major release, new `vN.x` and
1168 `vN.x-staging` branches (where `N` indicates the major release) should be
1169 created as forks of the `main` branch. Up until the cut-off date announced by
1172 The `vN.x` and `vN.x-staging` branches must be kept in sync with one another
1173 up until the date of the release.
1175 The TSC should be informed of any `SEMVER-MAJOR` commits that land within one
1176 month of the release.
1178 ### Create release labels
1183 * `backport-blocked-vN.x`
1184 * `backport-open-vN.x`
1185 * `backport-requested-vN.x`
1186 * `backported-to-vN.x`
1187 * `dont-land-on-vN.x`
1193 ### Release proposal
1195 A draft release proposal should be created 6 weeks before the release. A
1196 separate `vN.x-proposal` branch should be created that tracks the `vN.x`
1197 branch. This branch will contain the draft release commit (with the draft
1200 Notify the `@nodejs/npm` team in the release proposal PR to inform them of the
1201 upcoming release. `npm` maintains a list of [supported versions](https://github.com/npm/cli/blob/la…
1202 that will need updating to include the new major release.
1210   [NAN](https://github.com/nodejs/nan) uses it to form a compatibility-layer for
1212 * Determining the ABI for downloading pre-built binaries of native addons, e.g.
1213   [node-pre-gyp](https://github.com/mapbox/node-pre-gyp) uses this value as
1215   binary to download at install-time.
1218 and also if there are non-trivial API changes. The rules are not yet strictly
1226 reflect the newly used value. Ensure that the release commit removes the
1227 `-pre` suffix for the major version being prepared.
1230 see a need to bump `NODE_MODULE_VERSION` outside of a major release then
1234 ### Test releases and release candidates
1236 Test builds should be generated from the `vN.x-proposal` branch starting at
1237 about 6 weeks before the release.
1239 Release Candidates should be generated from the `vN.x-proposal` branch starting
1240 at about 4 weeks before the release, with a target of one release candidate
1243 Always run test releases and release candidates through the Canary in the
1248 Generating major release changelogs is a bit more involved than minor and patch
1251 #### Create the changelog file
1253 In the `doc/changelogs` directory, create a new `CHANGELOG_V{N}.md` file where
1254 `{N}` is the major version of the release. Follow the structure of the existing
1261 reference the newly-created major release `CHANGELOG_V{N}.md`.
1265 To generate a proper major release changelog, use the `branch-diff` tool to
1266 compare the `vN.x` branch against the `vN-1.x` branch (e.g. for Node.js 12.0,
1272 * Remove all release commits from the list
1274 * Separate all SEMVER-MAJOR, SEMVER-MINOR, and SEMVER-PATCH commits into lists
1278 For a major release, all SEMVER-MAJOR commits that are not strictly internal,
1279 test, or doc-related are to be listed as notable changes. Some SEMVER-MINOR
1280 commits may be listed as notable changes on a case-by-case basis. Use your
1287 for the new release line as a new file, `v{N}.x` (where `{N}` is the major
1288 version of the release), in the [expected assets][] folder. The change will
1289 need to be deployed onto the web server by a member of the [build-infra team][]
1290 before the release is promoted.
1295 specified a release line ("track" in Snap terminology). This should be updated
1302 …: https://github.com/nodejs/build/blob/HEAD/doc/jenkins-guide.md#restricting-access-for-security-r…
1304 [Partner Communities]: https://github.com/nodejs/community-committee/blob/HEAD/governance/PARTNER_C…
1306 [build-infra team]: https://github.com/orgs/nodejs/teams/build-infra
1307 [expected assets]: https://github.com/nodejs/build/tree/HEAD/ansible/www-standalone/tools/promote/e…
1308 [nodejs.org release-post.js script]: https://github.com/nodejs/nodejs.org/blob/HEAD/scripts/release…