doc: apply sentence-case to release doc headers

Our style is to use sentence case for headers and documentation titles.
The documentation for releases uses both sentence case and title case.
This change applies setnece case consistently throughout.

doc/guides/releases.md

@@ -1,11 +1,11 @@
-# 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 <https://nodejs.org/>.
 
-## Table of Contents
+## Table of contents
 
 * [Who can make a release?](#who-can-make-a-release)
   * [1. Jenkins Release Access](#1-jenkins-release-access)
@@ -42,7 +42,7 @@ official release builds for Node.js, hosted on <https://nodejs.org/>.
 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. <nodejs.org> Access
+### 2. <nodejs.org> access
 
 The _dist_ user on nodejs.org controls the assets available in
 <https://nodejs.org/download/>. <https://nodejs.org/dist/> 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 <vx.y.z> <commit-sha> -sm "YYYY-MM-DD Node.js vx.y.z (<release-
 The tag **must** be signed using the GPG key that's listed for you on the
 project README.
 
-### 12. Set Up For the Next Release
+### 12. Set up for the next release
 
 On release proposal branch, edit `src/node_version.h` again and:
 
@@ -536,7 +536,7 @@ $ git rebase v1.x
 $ git push upstream v1.x-staging
 ```
 
-### 13. Cherry-pick the Release Commit to `master`
+### 13. Cherry-pick the release commit to `master`
 
 ```console
 $ git checkout master
@@ -579,7 +579,7 @@ $ git push <remote> <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
 <https://nodejs.org/dist/latest/>. 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 <https://nodejs.org/api/>. Check that the release catalog files are correct
 at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
 
-### 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.