mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-20 10:39:49 +01:00
Code Issues Projects Releases Wiki Activity
0e2ec27576
core-lightning/doc/MAKING-RELEASES.md
Rusty Russell 04a57ae4af doc/MAKING-RELEASES.md: update. 
1. These days we delete the [Unreleased] tag during rcs.
2. Make sure we test the release build process during rc1, since I
   screwed that up last release.
3. Add a section on rc2, etc.
4. Do final release via a github PR, since I screwed that up on the
   prior release.
5. Update `tools/build-release.sh` and instructions to show that we now
   make a reproducible build for Ubuntu 18.04 x86-64.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-08-19 03:43:13 +00:00

2.8 KiB
Raw Blame History

Release checklist

Here's a checklist for the release process.

Leading Up To The Release

  1. Talk to team about whether there are any changes which MUST go in this release which may cause delay.
  2. Create a milestone for the next release, and go though issues and PR and mark accordingly.
  3. Ask the most significant contributor who has not already named a release to name the release (use devtools/credit). CC previous namers and team.

Prepering for -rc1

  1. Check that CHANGELOG.md is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness.
  2. Update the CHANGELOG.md with [Unreleased] changed to -rc1.
  3. Create a PR with the above.

Releasing -rc1

  1. Merge the PR above.
  2. Tag it git pull && git tag -s v<VERSION>rc1 && git push --tags
  3. Update the /topic on #c-lightning on Freenode.
  4. Prepare draft release notes (see devtools/credit), and share with team for editing.
  5. Upgrade your personal nodes to the rc1, to help testing.
  6. Test tools/build-release.sh to build the non-reprodicible images and reproducible zipfile.
  7. Use the zipfile to produce a reproducible build.

Releasing -rc2, etc

  1. Change rc1 to rc2 in CHANGELOG.md.
  2. Add a PR with the rc2.
  3. Tag it git pull && git tag -s v<VERSION>rc2 && git push --tags
  4. Update the /topic on #c-lightning on Freenode.
  5. Upgrade your personal nodes to the rc2.

Tagging the Release

  1. Update the CHANGELOG.md; remove -rcN in both places, and add an [Unreleased] footnote URL from this new version to HEAD.
  2. Add a PR with that release.
  3. Merge the PR, then git pull && git tag -s v<VERSION> && git push --tags.
  4. Run tools/build-release.sh to build the non-reprodicible images and reproducible zipfile.
  5. Use the zipfile to produce a reproducible build.
  6. Create the checksums for signing: sha256sum release/* > release/SHA256SUMS
  7. Create the first signature with gpg -sb --armor release/SHA256SUMS
  8. Upload the files resulting files to github and save as a draft. (https://github.com/ElementsProject/lightning/releases/)
  9. Ping the rest of the team to check the SHA256SUMS file and have them send their gpg -sb --armor SHA256SUMS.
  10. Append the signatures into a file called SHA256SUMS.asc, verify with gpg --verify SHA256SUMS.asc and include the file in the draft release.

Performing the Release

  1. Edit the GitHub draft and include the SHA256SUMS.asc file.
  2. Publish the release as not a draft.
  3. Update the /topic on #c-lightning on Freenode.
  4. Send a mail to c-lightning and lightning-dev mailing lists, using the same wording as the Release Notes in github.

Post-release

  1. Add a new '[Unreleased]' section the CHANGELOG.md with empty headers.
  2. Look through PRs which were delayed for release and merge them.