FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

doc: apply sentence case to release doc headers · nodejs/node@569ad98 · GitHub

/ node Public

Commit 569ad98

Browse files
Trott
authored and
targos
committed
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 sentence case consistently throughout. PR-URL: #37349 Reviewed-By: Darshan Sen <raisinten@gmail.com> Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
1 parent 7cf4a4b commit 569ad98

1 file changed

Lines changed: 41 additions & 41 deletions

File tree

‎doc/guides/releases.md‎

Lines changed: 41 additions & 41 deletions
Original file line numberDiff line numberDiff line change
@@ -1,48 +1,48 @@
1-
# Node.js Release Process
1+
# Node.js release process
22

33
This document describes the technical aspects of the Node.js release process.
44
The intended audience is those who have been authorized by the Node.js
55
Technical Steering Committee (TSC) to create, promote, and sign
66
official release builds for Node.js, hosted on <https://nodejs.org/>.
77

8-
## Table of Contents
8+
## Table of contents
99

1010
* [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)
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)
1414
* [How to create a release](#how-to-create-a-release)
1515
* [0. Pre-release steps](#0-pre-release-steps)
1616
* [1. Update the staging branch](#1-update-the-staging-branch)
1717
* [2. Create a new branch for the release](#2-create-a-new-branch-for-the-release)
1818
* [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-
* [8. Produce a Nightly Build _(optional)_](#8-produce-a-nightly-build-optional)
24-
* [9. Produce Release Builds](#9-produce-release-builds)
25-
* [10. Test the Build](#10-test-the-build)
26-
* [11. Tag and Sign the Release Commit](#11-tag-and-sign-the-release-commit)
27-
* [12. Set Up For the Next Release](#12-set-up-for-the-next-release)
28-
* [13. Cherry-pick the Release Commit to `master`](#13-cherry-pick-the-release-commit-to-master)
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+
* [8. Produce a nightly build _(optional)_](#8-produce-a-nightly-build-optional)
24+
* [9. Produce release builds](#9-produce-release-builds)
25+
* [10. Test the build](#10-test-the-build)
26+
* [11. Tag and sign the release commit](#11-tag-and-sign-the-release-commit)
27+
* [12. Set up for the next release](#12-set-up-for-the-next-release)
28+
* [13. Cherry-pick the release commit to `master`](#13-cherry-pick-the-release-commit-to-master)
2929
* [14. Push the release tag](#14-push-the-release-tag)
30-
* [15. Promote and Sign the Release Builds](#15-promote-and-sign-the-release-builds)
31-
* [16. Check the Release](#16-check-the-release)
32-
* [17. Create a Blog Post](#17-create-a-blog-post)
30+
* [15. Promote and sign the release builds](#15-promote-and-sign-the-release-builds)
31+
* [16. Check the release](#16-check-the-release)
32+
* [17. Create a blog post](#17-create-a-blog-post)
3333
* [18. Create the release on GitHub](#18-create-the-release-on-github)
3434
* [19. Cleanup](#19-cleanup)
3535
* [20. Announce](#20-announce)
3636
* [21. Celebrate](#21-celebrate)
37-
* [LTS Releases](#lts-releases)
38-
* [Major Releases](#major-releases)
37+
* [LTS releases](#lts-releases)
38+
* [Major releases](#major-releases)
3939

4040
## Who can make a release?
4141

4242
Release authorization is given by the Node.js TSC. Once authorized, an
4343
individual must have the following:
4444

45-
### 1. Jenkins Release Access
45+
### 1. Jenkins release access
4646

4747
There are three relevant Jenkins jobs that should be used for a release flow:
4848

@@ -64,7 +64,7 @@ a manual step once they are ready (see below).
6464
The [Node.js build team](https://github.com/nodejs/build) is able to provide
6565
this access to individuals authorized by the TSC.
6666

67-
### 2. <nodejs.org> Access
67+
### 2. <nodejs.org> access
6868

6969
The _dist_ user on nodejs.org controls the assets available in
7070
<https://nodejs.org/download/>. <https://nodejs.org/dist/> is an alias for
@@ -82,7 +82,7 @@ server as the _dist_ user. The
8282
[Node.js build team](https://github.com/nodejs/build) is able to provide this
8383
access to individuals authorized by the TSC.
8484

85-
### 3. A Publicly Listed GPG Key
85+
### 3. A publicly-listed GPG key
8686

8787
A `SHASUMS256.txt` file is produced for every promoted build, nightly, and
8888
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
258258
see a need to bump `NODE_MODULE_VERSION` then you should consult the TSC.
259259
Commits may need to be reverted or a major version bump may need to happen.
260260

261-
### 4. Update the Changelog
261+
### 4. Update the changelog
262262

263263
#### Step 1: Collect the formatted list of changes
264264

@@ -344,7 +344,7 @@ must be assigned a number (e.g. `DEP0012`). This assignment should
344344
occur when the PR is landed, but a check will be made when the release build is
345345
run.
346346

347-
### 5. Create Release Commit
347+
### 5. Create release commit
348348

349349
The `CHANGELOG.md`, `doc/changelogs/CHANGELOG_Vx.md`, `src/node_version.h`, and
350350
`REPLACEME` changes should be the final commit that will be tagged for the
@@ -373,7 +373,7 @@ Notable changes:
373373
* Copy the notable changes list here, reformatted for plain-text
374374
```
375375

376-
### 6. Propose Release on GitHub
376+
### 6. Propose release on GitHub
377377

378378
Push the release branch to `nodejs/node`, not to your own fork. This allows
379379
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.
391391
After opening the PR, update the release commit to include `PR-URL` metadata and
392392
force-push the proposal.
393393

394-
### 7. Ensure that the Release Branch is Stable
394+
### 7. Ensure that the release branch is stable
395395

396396
Run a **[`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)**
397397
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
406406
proposal branch to check if new regressions could be introduced in the
407407
ecosystem.
408408

409-
### 8. Produce a Nightly Build _(optional)_
409+
### 8. Produce a nightly build _(optional)_
410410

411411
If there is a reason to produce a test release for the purpose of having others
412412
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
418418
This is particularly recommended if there has been recent work relating to the
419419
macOS or Windows installers as they are not tested in any way by CI.
420420

421-
### 9. Produce Release Builds
421+
### 9. Produce release builds
422422

423423
Use **[iojs+release](https://ci-release.nodejs.org/job/iojs+release/)** to
424424
produce release artifacts. Enter the commit that you want to build from and
@@ -464,14 +464,14 @@ can use the
464464
build in the release CI to re-run the build only for ARMv6. When launching the
465465
build make sure to use the same commit hash as for the original release.
466466

467-
### 10. Test the Build
467+
### 10. Test the build
468468

469469
Jenkins collects the artifacts from the builds, allowing you to download and
470470
install the new build. Make sure that the build appears correct. Check the
471471
version numbers, and perform some basic checks to confirm that all is well with
472472
the build before moving forward.
473473

474-
### 11. Tag and Sign the Release Commit
474+
### 11. Tag and sign the release commit
475475

476476
Once you have produced builds that you're happy with, create a new tag. By
477477
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-
506506
The tag **must** be signed using the GPG key that's listed for you on the
507507
project README.
508508

509-
### 12. Set Up For the Next Release
509+
### 12. Set up for the next release
510510

511511
On release proposal branch, edit `src/node_version.h` again and:
512512

@@ -536,7 +536,7 @@ $ git rebase v1.x
536536
$ git push upstream v1.x-staging
537537
```
538538

539-
### 13. Cherry-pick the Release Commit to `master`
539+
### 13. Cherry-pick the release commit to `master`
540540

541541
```console
542542
$ git checkout master
@@ -579,7 +579,7 @@ $ git push <remote> <vx.y.z>
579579
*Note*: Please do not push the tag unless you are ready to complete the
580580
remainder of the release steps.
581581

582-
### 15. Promote and Sign the Release Builds
582+
### 15. Promote and sign the release builds
583583

584584
**The same individual who signed the release tag must be the one
585585
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`.
655655
**It is possible to only sign a release by running `./tools/release.sh -s
656656
vX.Y.Z`.**
657657

658-
### 16. Check the Release
658+
### 16. Check the release
659659

660660
Your release should be available at `https://nodejs.org/dist/vx.y.z/` and
661661
<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
664664
at <https://nodejs.org/api/>. Check that the release catalog files are correct
665665
at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.
666666

667-
### 17. Create a Blog Post
667+
### 17. Create a blog post
668668

669669
There is an automatic build that is kicked off when you promote new builds, so
670670
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..._
732732

733733
## LTS Releases
734734

735-
### Marking a Release Line as LTS
735+
### Marking a release line as LTS
736736

737737
To mark a release line as LTS, the following changes must be made to
738738
`src/node_version.h`:
@@ -770,7 +770,7 @@ existing labels for that release line, such as `vN.x`.
770770
If the release is transitioning from Active LTS to Maintenance, the
771771
`backport-requested-vN.x` label must be deleted.
772772

773-
## Major Releases
773+
## Major releases
774774

775775
The process for cutting a new Node.js major release has a number of differences
776776
from cutting a minor or patch release.
@@ -791,7 +791,7 @@ The release date for the next major release should be announced immediately
791791
following the current release (e.g. the release date for 13.0.0 should be
792792
announced immediately following the release of 12.0.0).
793793

794-
### Release Branch
794+
### Release branch
795795

796796
Approximately three months before a major release, new `vN.x` and
797797
`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.
821821
The label color must be the same for all new labels, but different from the
822822
labels of previous releases.
823823

824-
### Release Proposal
824+
### Release proposal
825825

826826
A draft release proposal should be created two months before the release. A
827827
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
832832
upcoming release. `npm` maintains a list of [supported versions](https://github.com/npm/cli/blob/latest/lib/utils/unsupported.js#L3)
833833
that will need updating to include the new major release.
834834

835-
### Test Releases and Release Candidates
835+
### Test releases and release candidates
836836

837837
Test builds should be generated from the `vN.x-proposal` branch starting at
838838
about 6 weeks before the release.

0 commit comments

Comments
 (0)
Back | FazBrowse Home | New Git URL