Commit a468392
doc: update releases guide re pushing tags
Currently we specify pushing the tag before updating any of the
branches. This creates a potential of creating and pushing a tag
on an out of sync branch, and only really when attempting to merge
the release commit that things have gone out of sync.
Changing the order here would minimize the possibility of this error
PR-URL: #31855
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Shelley Vohr <codebytere@gmail.com>
Reviewed-By: Beth Griggs <Bethany.Griggs@uk.ibm.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Trivikram Kamat <trivikr.dev@gmail.com>1 parent 8fa6373 commit a468392
1 file changed
Lines changed: 20 additions & 18 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -498,17 +498,6 @@ $ git secure-tag <vx.y.z> <commit-sha> -sm "YYYY-MM-DD Node.js vx.y.z (<release- | |||
| 498 | 498 | The tag **must** be signed using the GPG key that's listed for you on the | |
| 499 | 499 | project README. | |
| 500 | 500 | ||
| 501 | - Push the tag to the repo before you promote the builds. If you haven't pushed | ||
| 502 | - your tag first, then build promotion won't work properly. Push the tag using the | ||
| 503 | - following command: | ||
| 504 | - | ||
| 505 | - ```console | ||
| 506 | - $ git push <remote> <vx.y.z> | ||
| 507 | - ``` | ||
| 508 | - | ||
| 509 | - *Note*: Please do not push the tag unless you are ready to complete the | ||
| 510 | - remainder of the release steps. | ||
| 511 | - | ||
| 512 | 501 | ### 12. Set Up For the Next Release | |
| 513 | 502 | ||
| 514 | 503 | On release proposal branch, edit `src/node_version.h` again and: | |
@@ -547,7 +536,20 @@ cherry-pick the "Working on vx.y.z" commit to `master`. | |||
| 547 | 536 | Run `make lint` before pushing to `master`, to make sure the Changelog | |
| 548 | 537 | formatting passes the lint rules on `master`. | |
| 549 | 538 | ||
| 550 | - ### 13. Promote and Sign the Release Builds | ||
| 539 | + ### 13. Push the release tag | ||
| 540 | + | ||
| 541 | + Push the tag to the repo before you promote the builds. If you haven't pushed | ||
| 542 | + your tag first, then build promotion won't work properly. Push the tag using the | ||
| 543 | + following command: | ||
| 544 | + | ||
| 545 | + ```console | ||
| 546 | + $ git push <remote> <vx.y.z> | ||
| 547 | + ``` | ||
| 548 | + | ||
| 549 | + *Note*: Please do not push the tag unless you are ready to complete the | ||
| 550 | + remainder of the release steps. | ||
| 551 | + | ||
| 552 | + ### 14. Promote and Sign the Release Builds | ||
| 551 | 553 | ||
| 552 | 554 | **The same individual who signed the release tag must be the one | |
| 553 | 555 | to promote the builds as the `SHASUMS256.txt` file needs to be signed with the | |
@@ -620,7 +622,7 @@ be prompted to re-sign `SHASUMS256.txt`. | |||
| 620 | 622 | **It is possible to only sign a release by running `./tools/release.sh -s | |
| 621 | 623 | vX.Y.Z`.** | |
| 622 | 624 | ||
| 623 | - ### 14. Check the Release | ||
| 625 | + ### 15. Check the Release | ||
| 624 | 626 | ||
| 625 | 627 | Your release should be available at `https://nodejs.org/dist/vx.y.z/` and | |
| 626 | 628 | <https://nodejs.org/dist/latest/>. Check that the appropriate files are in | |
@@ -629,7 +631,7 @@ have the right internal version strings. Check that the API docs are available | |||
| 629 | 631 | at <https://nodejs.org/api/>. Check that the release catalog files are correct | |
| 630 | 632 | at <https://nodejs.org/dist/index.tab> and <https://nodejs.org/dist/index.json>. | |
| 631 | 633 | ||
| 632 | - ### 15. Create a Blog Post | ||
| 634 | + ### 16. Create a Blog Post | ||
| 633 | 635 | ||
| 634 | 636 | There is an automatic build that is kicked off when you promote new builds, so | |
| 635 | 637 | within a few minutes nodejs.org will be listing your new version as the latest | |
@@ -662,19 +664,19 @@ This script will use the promoted builds and changelog to generate the post. Run | |||
| 662 | 664 | * Changes to `master` on the [nodejs.org repository][] will trigger a new build | |
| 663 | 665 | of nodejs.org so your changes should appear a few minutes after pushing. | |
| 664 | 666 | ||
| 665 | - ### 16. Create the release on GitHub | ||
| 667 | + ### 17. Create the release on GitHub | ||
| 666 | 668 | ||
| 667 | 669 | * Go to the [New release page](https://github.com/nodejs/node/releases/new). | |
| 668 | 670 | * Select the tag version you pushed earlier. | |
| 669 | 671 | * For release title, copy the title from the changelog. | |
| 670 | 672 | * For the description, copy the rest of the changelog entry. | |
| 671 | 673 | * Click on the "Publish release" button. | |
| 672 | 674 | ||
| 673 | - ### 17. Cleanup | ||
| 675 | + ### 18. Cleanup | ||
| 674 | 676 | ||
| 675 | 677 | Close your release proposal PR and delete the proposal branch. | |
| 676 | 678 | ||
| 677 | - ### 18. Announce | ||
| 679 | + ### 19. Announce | ||
| 678 | 680 | ||
| 679 | 681 | The nodejs.org website will automatically rebuild and include the new version. | |
| 680 | 682 | To announce the build on Twitter through the official @nodejs account, email | |
@@ -691,7 +693,7 @@ announcements. | |||
| 691 | 693 | ||
| 692 | 694 | Ping the IRC ops and the other [Partner Communities][] liaisons. | |
| 693 | 695 | ||
| 694 | - ### 19. Celebrate | ||
| 696 | + ### 20. Celebrate | ||
| 695 | 697 | ||
| 696 | 698 | _In whatever form you do this..._ | |
| 697 | 699 | ||
0 commit comments