Skip to content

Commit

Permalink
doc: improve release documentation
Browse files Browse the repository at this point in the history
Extract the "Cherry-pick the Release Commit to master" part to its own
section and be more precise about what should be done to handle
conflicts.

PR-URL: #33042
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Reviewed-By: Myles Borins <myles.borins@gmail.com>
Reviewed-By: Anto Aravinth <anto.aravinth.cse@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
  • Loading branch information
targos authored and BridgeAR committed Apr 28, 2020
1 parent c318a52 commit c489a7e
Showing 1 changed file with 39 additions and 21 deletions.
60 changes: 39 additions & 21 deletions doc/guides/releases.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,13 +25,15 @@ official release builds for Node.js, hosted on <https://nodejs.org/>.
* [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. Promote and Sign the Release Builds](#13-promote-and-sign-the-release-builds)
* [14. Check the Release](#14-check-the-release)
* [15. Create a Blog Post](#15-create-a-blog-post)
* [16. Create the release on GitHub](#16-create-the-release-on-github)
* [17. Cleanup](#17-cleanup)
* [18. Announce](#18-announce)
* [19. Celebrate](#19-celebrate)
* [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)
* [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)

Expand Down Expand Up @@ -528,15 +530,31 @@ $ git rebase v1.x
$ git push upstream v1.x-staging
```

Cherry-pick the release commit to `master`. After cherry-picking, edit
`src/node_version.h` to ensure the version macros contain whatever values were
previously on `master`. `NODE_VERSION_IS_RELEASE` should be `0`. **Do not**
cherry-pick the "Working on vx.y.z" commit to `master`.
### 13. Cherry-pick the Release Commit to `master`

Run `make lint` before pushing to `master`, to make sure the Changelog
formatting passes the lint rules on `master`.
```console
$ git checkout master
$ git cherry-pick v1.x^
```

Git should stop to let you fix conflicts. Revert all changes that were made to
`src/node_version.h`. If there are conflicts in `doc` due to updated `REPLACEME`
placeholders (that happens when a change previously landed on another release
branch), keep both version numbers. Convert the YAML field to an array if it is
not already one.

Then finish cherry-picking and push the commit upstream:

```console
$ git add src/node_version.h doc
$ git cherry-pick --continue
$ make lint
$ git push upstream master
```

**Do not** cherry-pick the "Working on vx.y.z" commit to `master`.

### 13. Push the release tag
### 14. Push the release tag

Push the tag to the repo before you promote the builds. If you haven't pushed
your tag first, then build promotion won't work properly. Push the tag using the
Expand All @@ -549,7 +567,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.

### 14. 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
Expand Down Expand Up @@ -622,7 +640,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`.**

### 15. 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
Expand All @@ -631,7 +649,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>.

### 16. 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
Expand Down Expand Up @@ -664,19 +682,19 @@ This script will use the promoted builds and changelog to generate the post. Run
* Changes to `master` on the [nodejs.org repository][] will trigger a new build
of nodejs.org so your changes should appear a few minutes after pushing.

### 17. Create the release on GitHub
### 18. Create the release on GitHub

* Go to the [New release page](https://github.com/nodejs/node/releases/new).
* Select the tag version you pushed earlier.
* For release title, copy the title from the changelog.
* For the description, copy the rest of the changelog entry.
* Click on the "Publish release" button.

### 18. Cleanup
### 19. Cleanup

Close your release proposal PR and delete the proposal branch.

### 19. Announce
### 20. Announce

The nodejs.org website will automatically rebuild and include the new version.
To announce the build on Twitter through the official @nodejs account, email
Expand All @@ -693,7 +711,7 @@ announcements.

Ping the IRC ops and the other [Partner Communities][] liaisons.

### 20. Celebrate
### 21. Celebrate

_In whatever form you do this..._

Expand Down

0 comments on commit c489a7e

Please sign in to comment.