1## Release checklist
2
3Here's a checklist for the release process.
4
5### Leading Up To The Release
6
71. Talk to team about whether there are any changes which MUST go in
8   this release which may cause delay.
92. Look through outstanding issues, to identify any problems that might
10   be necessary to fixup before the release. Good candidates are reports
11   of the project not building on different architectures or crashes.
123. Identify a good lead for each outstanding issue, and ask them about
13   a fix timeline.
144. Create a milestone for the *next* release on Github, and go though
15   open issues and PRs and mark accordingly.
165. Ask (via email) the most significant contributor who has not
17   already named a release to name the release (use devtools/credit to
18   find this contributor). CC previous namers and team.
19
20### Preparing for -rc1
21
221. Check that `CHANGELOG.md` is well formatted, ordered in areas,
23   covers all signficant changes, and sub-ordered approximately by user impact
24   & coolness.
252. Use `devtools/changelog.py` to collect the changelog entries from pull
26   request commit messages and merge them into the manually maintained
27   `CHANGELOG.md`.  This does API queries to GitHub, which are severely
28   ratelimited unless you use an API token: set the `GH_TOKEN` environment
29   variable to a Personal Access Token from https://github.com/settings/tokens
303. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at
31   the bottom. Note that you should exactly copy the date and name format from
32   a previous release, as the `build-release.sh` script relies on this.
334. Update the contrib/pyln package __version__ strings, but do not upload
34   it to pypi!
355. Create a PR with the above.
36
37### Releasing -rc1
38
391. Merge the above PR.
402. Tag it `git pull && git tag -s v<VERSION>rc1`. Note that you
41   should get a prompt to give this tag a 'message'. Make sure you fill this in.
423. Confirm that the tag will show up for builds with `git describe`
434. Push the tag to remote `git push --tags`.
443. Update the /topic on #c-lightning on Libera.
454. Prepare draft release notes (see devtools/credit), and share with team for editing.
465. Upgrade your personal nodes to the rc1, to help testing.
476. Test `tools/build-release.sh` to build the non-reprodicible images
48   and reproducible zipfile.
497. Use the zipfile to produce a [reproducible build](REPRODUCIBLE.md).
50
51### Releasing -rc2, etc
52
531. Change rc1 to rc2 in CHANGELOG.md.
542. Add a PR with the rc2.
553. Tag it `git pull && git tag -s v<VERSION>rc2 && git push --tags`
564. Update the /topic on #c-lightning on Libera.
575. Upgrade your personal nodes to the rc2.
58
59### Tagging the Release
60
611. Update the CHANGELOG.md; remove -rcN in both places, update the date and add title and namer.
622. Add a PR with that release.
633. Merge the PR, then:
64   - `export VERSION=0.9.3`
65   - `git pull`
66   - `git tag -a -s v${VERSION} -m v${VERSION}`
67   - `git push --tags`
684. Run `tools/build-release.sh` to build the non-reprodicible images
69   and reproducible zipfile.
705. Use the zipfile to produce a [reproducible build](REPRODUCIBLE.md).
716. Create the checksums for signing: `sha256sum release/* > release/SHA256SUMS`
727. Create the first signature with `gpg -sb --armor release/SHA256SUMS`
738. Upload the files resulting files to github and
74   save as a draft.
75   (https://github.com/ElementsProject/lightning/releases/)
769. Ping the rest of the team to check the SHA256SUMS file and have them send their
77   `gpg -sb --armor SHA256SUMS`.
7810. Append the signatures into a file called `SHA256SUMS.asc`, verify
79   with `gpg --verify SHA256SUMS.asc` and include the file in the draft
80   release.
8111. In each contrib/pyln-* directory, `make test-release` and if that succeeds,
82    `make prod-release` to upload to pypi.org.
83
84### Performing the Release
85
861. Edit the GitHub draft and include the `SHA256SUMS.asc` file.
872. Publish the release as not a draft.
883. Update the /topic on #c-lightning on Libera.
894. Send a mail to c-lightning and lightning-dev mailing lists, using the
90   same wording as the Release Notes in github.
91
92### Post-release
93
941. Look through PRs which were delayed for release and merge them.
952. Close out the Milestone for the now-shipped release.
963. Update this file with any missing or changed instructions.
97