Commit 8a4de2e
doc: improve release documentation
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>1 parent 59b64ad commit 8a4de2e
1 file changed
Lines changed: 39 additions & 21 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -25,13 +25,15 @@ official release builds for Node.js, hosted on <https://nodejs.org/>. | |||
| 25 | 25 | * [10. Test the Build](#10-test-the-build) | |
| 26 | 26 | * [11. Tag and Sign the Release Commit](#11-tag-and-sign-the-release-commit) | |
| 27 | 27 | * [12. Set Up For the Next Release](#12-set-up-for-the-next-release) | |
| 28 | - * [13. Promote and Sign the Release Builds](#13-promote-and-sign-the-release-builds) | ||
| 29 | - * [14. Check the Release](#14-check-the-release) | ||
| 30 | - * [15. Create a Blog Post](#15-create-a-blog-post) | ||
| 31 | - * [16. Create the release on GitHub](#16-create-the-release-on-github) | ||
| 32 | - * [17. Cleanup](#17-cleanup) | ||
| 33 | - * [18. Announce](#18-announce) | ||
| 34 | - * [19. Celebrate](#19-celebrate) | ||
| 28 | + * [13. Cherry-pick the Release Commit to `master`](#13-cherry-pick-the-release-commit-to-master) | ||
| 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) | ||
| 33 | + * [18. Create the release on GitHub](#18-create-the-release-on-github) | ||
| 34 | + * [19. Cleanup](#19-cleanup) | ||
| 35 | + * [20. Announce](#20-announce) | ||
| 36 | + * [21. Celebrate](#21-celebrate) | ||
| 35 | 37 | * [LTS Releases](#lts-releases) | |
| 36 | 38 | * [Major Releases](#major-releases) | |
| 37 | 39 | ||
@@ -528,15 +530,31 @@ $ git rebase v1.x | |||
| 528 | 530 | $ git push upstream v1.x-staging | |
| 529 | 531 | ``` | |
| 530 | 532 | ||
| 531 | - Cherry-pick the release commit to `master`. After cherry-picking, edit | ||
| 532 | - `src/node_version.h` to ensure the version macros contain whatever values were | ||
| 533 | - previously on `master`. `NODE_VERSION_IS_RELEASE` should be `0`. **Do not** | ||
| 534 | - cherry-pick the "Working on vx.y.z" commit to `master`. | ||
| 533 | + ### 13. Cherry-pick the Release Commit to `master` | ||
| 535 | 534 | ||
| 536 | - Run `make lint` before pushing to `master`, to make sure the Changelog | ||
| 537 | - formatting passes the lint rules on `master`. | ||
| 535 | + ```console | ||
| 536 | + $ git checkout master | ||
| 537 | + $ git cherry-pick v1.x^ | ||
| 538 | + ``` | ||
| 539 | + | ||
| 540 | + Git should stop to let you fix conflicts. Revert all changes that were made to | ||
| 541 | + `src/node_version.h`. If there are conflicts in `doc` due to updated `REPLACEME` | ||
| 542 | + placeholders (that happens when a change previously landed on another release | ||
| 543 | + branch), keep both version numbers. Convert the YAML field to an array if it is | ||
| 544 | + not already one. | ||
| 545 | + | ||
| 546 | + Then finish cherry-picking and push the commit upstream: | ||
| 547 | + | ||
| 548 | + ```console | ||
| 549 | + $ git add src/node_version.h doc | ||
| 550 | + $ git cherry-pick --continue | ||
| 551 | + $ make lint | ||
| 552 | + $ git push upstream master | ||
| 553 | + ``` | ||
| 554 | + | ||
| 555 | + **Do not** cherry-pick the "Working on vx.y.z" commit to `master`. | ||
| 538 | 556 | ||
| 539 | - ### 13. Push the release tag | ||
| 557 | + ### 14. Push the release tag | ||
| 540 | 558 | ||
| 541 | 559 | Push the tag to the repo before you promote the builds. If you haven't pushed | |
| 542 | 560 | your tag first, then build promotion won't work properly. Push the tag using the | |
@@ -549,7 +567,7 @@ $ git push <remote> <vx.y.z> | |||
| 549 | 567 | *Note*: Please do not push the tag unless you are ready to complete the | |
| 550 | 568 | remainder of the release steps. | |
| 551 | 569 | ||
| 552 | - ### 14. Promote and Sign the Release Builds | ||
| 570 | + ### 15. Promote and Sign the Release Builds | ||
| 553 | 571 | ||
| 554 | 572 | **The same individual who signed the release tag must be the one | |
| 555 | 573 | to promote the builds as the `SHASUMS256.txt` file needs to be signed with the | |
@@ -622,7 +640,7 @@ be prompted to re-sign `SHASUMS256.txt`. | |||
| 622 | 640 | **It is possible to only sign a release by running `./tools/release.sh -s | |
| 623 | 641 | vX.Y.Z`.** | |
| 624 | 642 | ||
| 625 | - ### 15. Check the Release | ||
| 643 | + ### 16. Check the Release | ||
| 626 | 644 | ||
| 627 | 645 | Your release should be available at `https://nodejs.org/dist/vx.y.z/` and | |
| 628 | 646 | <https://nodejs.org/dist/latest/>. Check that the appropriate files are in | |
@@ -631,7 +649,7 @@ have the right internal version strings. Check that the API docs are available | |||
| 631 | 649 | at <https://nodejs.org/api/>. Check that the release catalog files are correct | |
| 632 | 650 | at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>. | |
| 633 | 651 | ||
| 634 | - ### 16. Create a Blog Post | ||
| 652 | + ### 17. Create a Blog Post | ||
| 635 | 653 | ||
| 636 | 654 | There is an automatic build that is kicked off when you promote new builds, so | |
| 637 | 655 | within a few minutes nodejs.org will be listing your new version as the latest | |
@@ -664,19 +682,19 @@ This script will use the promoted builds and changelog to generate the post. Run | |||
| 664 | 682 | * Changes to `master` on the [nodejs.org repository][] will trigger a new build | |
| 665 | 683 | of nodejs.org so your changes should appear a few minutes after pushing. | |
| 666 | 684 | ||
| 667 | - ### 17. Create the release on GitHub | ||
| 685 | + ### 18. Create the release on GitHub | ||
| 668 | 686 | ||
| 669 | 687 | * Go to the [New release page](https://github.com/nodejs/node/releases/new). | |
| 670 | 688 | * Select the tag version you pushed earlier. | |
| 671 | 689 | * For release title, copy the title from the changelog. | |
| 672 | 690 | * For the description, copy the rest of the changelog entry. | |
| 673 | 691 | * Click on the "Publish release" button. | |
| 674 | 692 | ||
| 675 | - ### 18. Cleanup | ||
| 693 | + ### 19. Cleanup | ||
| 676 | 694 | ||
| 677 | 695 | Close your release proposal PR and delete the proposal branch. | |
| 678 | 696 | ||
| 679 | - ### 19. Announce | ||
| 697 | + ### 20. Announce | ||
| 680 | 698 | ||
| 681 | 699 | The nodejs.org website will automatically rebuild and include the new version. | |
| 682 | 700 | To announce the build on Twitter through the official @nodejs account, email | |
@@ -693,7 +711,7 @@ announcements. | |||
| 693 | 711 | ||
| 694 | 712 | Ping the IRC ops and the other [Partner Communities][] liaisons. | |
| 695 | 713 | ||
| 696 | - ### 20. Celebrate | ||
| 714 | + ### 21. Celebrate | ||
| 697 | 715 | ||
| 698 | 716 | _In whatever form you do this..._ | |
| 699 | 717 | ||
0 commit comments