GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — doc: apply sentence case to release doc headers · nodejs/node@189ce39

File tree

Expand file treeCollapse file tree

Open diff view settings

Filter options

doc/guides
- releases.md

Expand file treeCollapse file tree

Open diff view settings

Collapse file

`‎doc/guides/releases.md‎`

Copy file name to clipboardExpand all lines: doc/guides/releases.md

+41-41Lines changed: 41 additions & 41 deletions

Display the source diff
Display the rich diff

Original file line number	Diff line number	Diff line change
`@@ -1,48 +1,48 @@`
`1`		`-# Node.js Release Process`
	`1`	`+# Node.js release process`
`2`	`2`
`3`	`3`	`This document describes the technical aspects of the Node.js release process.`
`4`	`4`	`The intended audience is those who have been authorized by the Node.js`
`5`	`5`	`Technical Steering Committee (TSC) to create, promote, and sign`
`6`	`6`	`official release builds for Node.js, hosted on <https://nodejs.org/>.`
`7`	`7`
`8`		`-## Table of Contents`
	`8`	`+## Table of contents`
`9`	`9`
`10`	`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)`
	`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`	`14`	`* [How to create a release](#how-to-create-a-release)`
`15`	`15`	`* [0. Pre-release steps](#0-pre-release-steps)`
`16`	`16`	`* [1. Update the staging branch](#1-update-the-staging-branch)`
`17`	`17`	`* [2. Create a new branch for the release](#2-create-a-new-branch-for-the-release)`
`18`	`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`		`- * [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)
`29`	`29`	`* [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)`
`33`	`33`	`* [18. Create the release on GitHub](#18-create-the-release-on-github)`
`34`	`34`	`* [19. Cleanup](#19-cleanup)`
`35`	`35`	`* [20. Announce](#20-announce)`
`36`	`36`	`* [21. Celebrate](#21-celebrate)`
`37`		`-* [LTS Releases](#lts-releases)`
`38`		`-* [Major Releases](#major-releases)`
	`37`	`+* [LTS releases](#lts-releases)`
	`38`	`+* [Major releases](#major-releases)`
`39`	`39`
`40`	`40`	`## Who can make a release?`
`41`	`41`
`42`	`42`	`Release authorization is given by the Node.js TSC. Once authorized, an`
`43`	`43`	`individual must have the following:`
`44`	`44`
`45`		`-### 1. Jenkins Release Access`
	`45`	`+### 1. Jenkins release access`
`46`	`46`
`47`	`47`	`There are three relevant Jenkins jobs that should be used for a release flow:`
`48`	`48`
`@@ -64,7 +64,7 @@ a manual step once they are ready (see below).`
`64`	`64`	`The [Node.js build team](https://github.com/nodejs/build) is able to provide`
`65`	`65`	`this access to individuals authorized by the TSC.`
`66`	`66`
`67`		`-### 2. <nodejs.org> Access`
	`67`	`+### 2. <nodejs.org> access`
`68`	`68`
`69`	`69`	`The _dist_ user on nodejs.org controls the assets available in`
`70`	`70`	`<https://nodejs.org/download/>. <https://nodejs.org/dist/> is an alias for`
`@@ -82,7 +82,7 @@ server as the _dist_ user. The`
`82`	`82`	`[Node.js build team](https://github.com/nodejs/build) is able to provide this`
`83`	`83`	`access to individuals authorized by the TSC.`
`84`	`84`
`85`		`-### 3. A Publicly Listed GPG Key`
	`85`	`+### 3. A publicly-listed GPG key`
`86`	`86`
`87`	`87`	A `SHASUMS256.txt` file is produced for every promoted build, nightly, and
`88`	`88`	`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`
`258`	`258`	see a need to bump `NODE_MODULE_VERSION` then you should consult the TSC.
`259`	`259`	`Commits may need to be reverted or a major version bump may need to happen.`
`260`	`260`
`261`		`-### 4. Update the Changelog`
	`261`	`+### 4. Update the changelog`
`262`	`262`
`263`	`263`	`#### Step 1: Collect the formatted list of changes`
`264`	`264`
@@ -344,7 +344,7 @@ must be assigned a number (e.g. `DEP0012`). This assignment should
`344`	`344`	`occur when the PR is landed, but a check will be made when the release build is`
`345`	`345`	`run.`
`346`	`346`
`347`		`-### 5. Create Release Commit`
	`347`	`+### 5. Create release commit`
`348`	`348`
`349`	`349`	The `CHANGELOG.md`, `doc/changelogs/CHANGELOG_Vx.md`, `src/node_version.h`, and
`350`	`350`	`REPLACEME` changes should be the final commit that will be tagged for the
`@@ -373,7 +373,7 @@ Notable changes:`
`373`	`373`	`* Copy the notable changes list here, reformatted for plain-text`
`374`	`374`	```
`375`	`375`
`376`		`-### 6. Propose Release on GitHub`
	`376`	`+### 6. Propose release on GitHub`
`377`	`377`
`378`	`378`	Push the release branch to `nodejs/node`, not to your own fork. This allows
`379`	`379`	`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.`
`391`	`391`	After opening the PR, update the release commit to include `PR-URL` metadata and
`392`	`392`	`force-push the proposal.`
`393`	`393`
`394`		`-### 7. Ensure that the Release Branch is Stable`
	`394`	`+### 7. Ensure that the release branch is stable`
`395`	`395`
`396`	`396`	Run a [`node-test-pull-request`](https://ci.nodejs.org/job/node-test-pull-request/)
`397`	`397`	`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
`406`	`406`	`proposal branch to check if new regressions could be introduced in the`
`407`	`407`	`ecosystem.`
`408`	`408`
`409`		`-### 8. Produce a Nightly Build _(optional)_`
	`409`	`+### 8. Produce a nightly build _(optional)_`
`410`	`410`
`411`	`411`	`If there is a reason to produce a test release for the purpose of having others`
`412`	`412`	`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`
`418`	`418`	`This is particularly recommended if there has been recent work relating to the`
`419`	`419`	`macOS or Windows installers as they are not tested in any way by CI.`
`420`	`420`
`421`		`-### 9. Produce Release Builds`
	`421`	`+### 9. Produce release builds`
`422`	`422`
`423`	`423`	`Use [iojs+release](https://ci-release.nodejs.org/job/iojs+release/) to`
`424`	`424`	`produce release artifacts. Enter the commit that you want to build from and`
`@@ -464,14 +464,14 @@ can use the`
`464`	`464`	`build in the release CI to re-run the build only for ARMv6. When launching the`
`465`	`465`	`build make sure to use the same commit hash as for the original release.`
`466`	`466`
`467`		`-### 10. Test the Build`
	`467`	`+### 10. Test the build`
`468`	`468`
`469`	`469`	`Jenkins collects the artifacts from the builds, allowing you to download and`
`470`	`470`	`install the new build. Make sure that the build appears correct. Check the`
`471`	`471`	`version numbers, and perform some basic checks to confirm that all is well with`
`472`	`472`	`the build before moving forward.`
`473`	`473`
`474`		`-### 11. Tag and Sign the Release Commit`
	`474`	`+### 11. Tag and sign the release commit`
`475`	`475`
`476`	`476`	`Once you have produced builds that you're happy with, create a new tag. By`
`477`	`477`	`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-`
`506`	`506`	`The tag must be signed using the GPG key that's listed for you on the`
`507`	`507`	`project README.`
`508`	`508`
`509`		`-### 12. Set Up For the Next Release`
	`509`	`+### 12. Set up for the next release`
`510`	`510`
`511`	`511`	On release proposal branch, edit `src/node_version.h` again and:
`512`	`512`
`@@ -536,7 +536,7 @@ $ git rebase v1.x`
`536`	`536`	`$ git push upstream v1.x-staging`
`537`	`537`	```
`538`	`538`
`539`		-### 13. Cherry-pick the Release Commit to `master`
	`539`	+### 13. Cherry-pick the release commit to `master`
`540`	`540`
`541`	`541`	```console
`542`	`542`	`$ git checkout master`
`@@ -579,7 +579,7 @@ $ git push <remote> <vx.y.z>`
`579`	`579`	`Note: Please do not push the tag unless you are ready to complete the`
`580`	`580`	`remainder of the release steps.`
`581`	`581`
`582`		`-### 15. Promote and Sign the Release Builds`
	`582`	`+### 15. Promote and sign the release builds`
`583`	`583`
`584`	`584`	`**The same individual who signed the release tag must be the one`
`585`	`585`	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`.
`655`	`655`	**It is possible to only sign a release by running `./tools/release.sh -s
`656`	`656`	vX.Y.Z`.**
`657`	`657`
`658`		`-### 16. Check the Release`
	`658`	`+### 16. Check the release`
`659`	`659`
`660`	`660`	Your release should be available at `https://nodejs.org/dist/vx.y.z/` and
`661`	`661`	`<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`
`664`	`664`	`at <https://nodejs.org/api/>. Check that the release catalog files are correct`
`665`	`665`	`at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>.`
`666`	`666`
`667`		`-### 17. Create a Blog Post`
	`667`	`+### 17. Create a blog post`
`668`	`668`
`669`	`669`	`There is an automatic build that is kicked off when you promote new builds, so`
`670`	`670`	`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..._`
`732`	`732`
`733`	`733`	`## LTS Releases`
`734`	`734`
`735`		`-### Marking a Release Line as LTS`
	`735`	`+### Marking a release line as LTS`
`736`	`736`
`737`	`737`	`To mark a release line as LTS, the following changes must be made to`
`738`	`738`	`src/node_version.h`:
@@ -770,7 +770,7 @@ existing labels for that release line, such as `vN.x`.
`770`	`770`	`If the release is transitioning from Active LTS to Maintenance, the`
`771`	`771`	`backport-requested-vN.x` label must be deleted.
`772`	`772`
`773`		`-## Major Releases`
	`773`	`+## Major releases`
`774`	`774`
`775`	`775`	`The process for cutting a new Node.js major release has a number of differences`
`776`	`776`	`from cutting a minor or patch release.`
`@@ -791,7 +791,7 @@ The release date for the next major release should be announced immediately`
`791`	`791`	`following the current release (e.g. the release date for 13.0.0 should be`
`792`	`792`	`announced immediately following the release of 12.0.0).`
`793`	`793`
`794`		`-### Release Branch`
	`794`	`+### Release branch`
`795`	`795`
`796`	`796`	Approximately three months before a major release, new `vN.x` and
`797`	`797`	`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.`
`821`	`821`	`The label color must be the same for all new labels, but different from the`
`822`	`822`	`labels of previous releases.`
`823`	`823`
`824`		`-### Release Proposal`
	`824`	`+### Release proposal`
`825`	`825`
`826`	`826`	`A draft release proposal should be created two months before the release. A`
`827`	`827`	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
`832`	`832`	upcoming release. `npm` maintains a list of [supported versions](https://github.com/npm/cli/blob/latest/lib/utils/unsupported.js#L3)
`833`	`833`	`that will need updating to include the new major release.`
`834`	`834`
`835`		`-### Test Releases and Release Candidates`
	`835`	`+### Test releases and release candidates`
`836`	`836`
`837`	`837`	Test builds should be generated from the `vN.x-proposal` branch starting at
`838`	`838`	`about 6 weeks before the release.`

0 commit comments

Comments

0 (0)

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.