diff --git a/doc/guides/releases.md b/doc/guides/releases.md
index 903b31c744abc2..7fa86734e75420 100644
--- a/doc/guides/releases.md
+++ b/doc/guides/releases.md
@@ -1,48 +1,48 @@
-# Node.js Release Process
+# Node.js release process
This document describes the technical aspects of the Node.js release process.
The intended audience is those who have been authorized by the Node.js
Technical Steering Committee (TSC) to create, promote, and sign
official release builds for Node.js, hosted on .
-## Table of Contents
+## Table of contents
* [Who can make a release?](#who-can-make-a-release)
- * [1. Jenkins Release Access](#1-jenkins-release-access)
- * [2. Access](#2-nodejsorg-access)
- * [3. A Publicly Listed GPG Key](#3-a-publicly-listed-gpg-key)
+ * [1. Jenkins release access](#1-jenkins-release-access)
+ * [2. access](#2-nodejsorg-access)
+ * [3. A publicly listed GPG key](#3-a-publicly-listed-gpg-key)
* [How to create a release](#how-to-create-a-release)
* [0. Pre-release steps](#0-pre-release-steps)
* [1. Update the staging branch](#1-update-the-staging-branch)
* [2. Create a new branch for the release](#2-create-a-new-branch-for-the-release)
* [3. Update `src/node_version.h`](#3-update-srcnode_versionh)
- * [4. Update the Changelog](#4-update-the-changelog)
- * [5. Create Release Commit](#5-create-release-commit)
- * [6. Propose Release on GitHub](#6-propose-release-on-github)
- * [7. Ensure that the Release Branch is Stable](#7-ensure-that-the-release-branch-is-stable)
- * [8. Produce a Nightly Build _(optional)_](#8-produce-a-nightly-build-optional)
- * [9. Produce Release Builds](#9-produce-release-builds)
- * [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)
+ * [4. Update the changelog](#4-update-the-changelog)
+ * [5. Create release commit](#5-create-release-commit)
+ * [6. Propose release on GitHub](#6-propose-release-on-github)
+ * [7. Ensure that the release branch is stable](#7-ensure-that-the-release-branch-is-stable)
+ * [8. Produce a nightly build _(optional)_](#8-produce-a-nightly-build-optional)
+ * [9. Produce release builds](#9-produce-release-builds)
+ * [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)
* [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)
- * [17. Create a Blog Post](#17-create-a-blog-post)
+ * [15. Promote and sign the release builds](#15-promote-and-sign-the-release-builds)
+ * [16. Check the release](#16-check-the-release)
+ * [17. Create a blog post](#17-create-a-blog-post)
* [18. Create the release on GitHub](#18-create-the-release-on-github)
* [19. Cleanup](#19-cleanup)
* [20. Announce](#20-announce)
* [21. Celebrate](#21-celebrate)
-* [LTS Releases](#lts-releases)
-* [Major Releases](#major-releases)
+* [LTS releases](#lts-releases)
+* [Major releases](#major-releases)
## Who can make a release?
Release authorization is given by the Node.js TSC. Once authorized, an
individual must have the following:
-### 1. Jenkins Release Access
+### 1. Jenkins release access
There are three relevant Jenkins jobs that should be used for a release flow:
@@ -64,7 +64,7 @@ a manual step once they are ready (see below).
The [Node.js build team](https://github.com/nodejs/build) is able to provide
this access to individuals authorized by the TSC.
-### 2. Access
+### 2. access
The _dist_ user on nodejs.org controls the assets available in
. is an alias for
@@ -82,7 +82,7 @@ server as the _dist_ user. The
[Node.js build team](https://github.com/nodejs/build) is able to provide this
access to individuals authorized by the TSC.
-### 3. A Publicly Listed GPG Key
+### 3. A publicly-listed GPG key
A `SHASUMS256.txt` file is produced for every promoted build, nightly, and
releases. Additionally for releases, this file is signed by the individual
@@ -258,7 +258,7 @@ It is current TSC policy to bump major version when ABI changes. If you
see a need to bump `NODE_MODULE_VERSION` then you should consult the TSC.
Commits may need to be reverted or a major version bump may need to happen.
-### 4. Update the Changelog
+### 4. Update the changelog
#### Step 1: Collect the formatted list of changes
@@ -344,7 +344,7 @@ must be assigned a number (e.g. `DEP0012`). This assignment should
occur when the PR is landed, but a check will be made when the release build is
run.
-### 5. Create Release Commit
+### 5. Create release commit
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
@@ -373,7 +373,7 @@ Notable changes:
* Copy the notable changes list here, reformatted for plain-text
```
-### 6. Propose Release on GitHub
+### 6. Propose release on GitHub
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
@@ -391,7 +391,7 @@ good place to @-mention the relevant contributors.
After opening the PR, update the release commit to include `PR-URL` metadata and
force-push the proposal.
-### 7. Ensure that the Release Branch is Stable
+### 7. Ensure that the release branch is stable
Run a **[`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)**
test run to ensure that the build is stable and the HEAD commit is ready for
@@ -406,7 +406,7 @@ 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.
-### 8. Produce a Nightly Build _(optional)_
+### 8. Produce a nightly build _(optional)_
If there is a reason to produce a test release for the purpose of having others
try out installers or specifics of builds, produce a nightly build using
@@ -418,7 +418,7 @@ enter a proper length commit SHA, enter a date string, and select "nightly" for
This is particularly recommended if there has been recent work relating to the
macOS or Windows installers as they are not tested in any way by CI.
-### 9. Produce Release Builds
+### 9. Produce release builds
Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to
produce release artifacts. Enter the commit that you want to build from and
@@ -464,14 +464,14 @@ can use the
build in the release CI to re-run the build only for ARMv6. When launching the
build make sure to use the same commit hash as for the original release.
-### 10. Test the Build
+### 10. Test the build
Jenkins collects the artifacts from the builds, allowing you to download and
install the new build. Make sure that the build appears correct. Check the
version numbers, and perform some basic checks to confirm that all is well with
the build before moving forward.
-### 11. Tag and Sign the Release Commit
+### 11. Tag and sign the release commit
Once you have produced builds that you're happy with, create a new tag. By
waiting until this stage to create tags, you can discard a proposed release if
@@ -506,7 +506,7 @@ $ git secure-tag -sm "YYYY-MM-DD Node.js vx.y.z (
*Note*: Please do not push the tag unless you are ready to complete the
remainder of the release steps.
-### 15. Promote and Sign the Release Builds
+### 15. Promote and sign the release builds
**The same individual who signed the release tag must be the one
to promote the builds as the `SHASUMS256.txt` file needs to be signed with the
@@ -655,7 +655,7 @@ be prompted to re-sign `SHASUMS256.txt`.
**It is possible to only sign a release by running `./tools/release.sh -s
vX.Y.Z`.**
-### 16. Check the Release
+### 16. Check the release
Your release should be available at `https://nodejs.org/dist/vx.y.z/` and
. Check that the appropriate files are in
@@ -664,7 +664,7 @@ have the right internal version strings. Check that the API docs are available
at . Check that the release catalog files are correct
at and .
-### 17. Create a Blog Post
+### 17. Create a blog post
There is an automatic build that is kicked off when you promote new builds, so
within a few minutes nodejs.org will be listing your new version as the latest
@@ -732,7 +732,7 @@ _In whatever form you do this..._
## LTS Releases
-### Marking a Release Line as LTS
+### Marking a release line as LTS
To mark a release line as LTS, the following changes must be made to
`src/node_version.h`:
@@ -770,7 +770,7 @@ existing labels for that release line, such as `vN.x`.
If the release is transitioning from Active LTS to Maintenance, the
`backport-requested-vN.x` label must be deleted.
-## Major Releases
+## Major releases
The process for cutting a new Node.js major release has a number of differences
from cutting a minor or patch release.
@@ -791,7 +791,7 @@ The release date for the next major release should be announced immediately
following the current release (e.g. the release date for 13.0.0 should be
announced immediately following the release of 12.0.0).
-### Release Branch
+### Release branch
Approximately three months before a major release, new `vN.x` and
`vN.x-staging` branches (where `N` indicates the major release) should be
@@ -821,7 +821,7 @@ The label description can be copied from existing labels of previous releases.
The label color must be the same for all new labels, but different from the
labels of previous releases.
-### Release Proposal
+### Release proposal
A draft release proposal should be created two months before the release. A
separate `vN.x-proposal` branch should be created that tracks the `vN.x`
@@ -832,7 +832,7 @@ Notify the `@nodejs/npm` team in the release proposal PR to inform them of the
upcoming release. `npm` maintains a list of [supported versions](https://github.com/npm/cli/blob/latest/lib/utils/unsupported.js#L3)
that will need updating to include the new major release.
-### Test Releases and Release Candidates
+### Test releases and release candidates
Test builds should be generated from the `vN.x-proposal` branch starting at
about 6 weeks before the release.