doc: update release-checklist to make CHANGELOG.md more coherent.
What the developer wrote
Authored by Rusty Russell
doc: update release-checklist to make CHANGELOG.md more coherent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit only updates the project's internal release checklist documentation. It reorders the steps for preparing a release changelog so that maintainers first import changes from point releases, then merge new entries, then remove duplicates, and then format the result. There is no change to any software code, configuration, or security-sensitive process.
No security action needed. This is a documentation-only process improvement.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff modifies doc/contribute-to-core-lightning/release-checklist.md. It renumbers and reorders the ‘Preparing for -rc1’ section: step 1 now imports point-release CHANGELOG.md changes, step 2 runs devtools/changelog.py, step 3 checks formatting, step 4 removes duplicate entries from point releases, and steps 5-7 are the previous steps renumbered. No code, build scripts, cryptographic, network, or authentication logic is touched.
Changed components
doc/contribute-to-core-lightning/release-checklist.mdInspect captured patch +6 / −4
diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md
index 24456d14..89abf406 100644
--- a/doc/contribute-to-core-lightning/release-checklist.md
+++ b/doc/contribute-to-core-lightning/release-checklist.md
@@ -18,11 +18,13 @@ Here's a checklist for the release process.
## Preparing 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.
+1. Make sure any `CHANGELOG.md` changes from point releases have been imported.
2. Use `devtools/changelog.py` to collect the changelog entries from pull request commit messages and merge them into the manually maintained `CHANGELOG.md`. This does API queries to GitHub, which are severely ratelimited unless you use an API token: set the `GH_TOKEN` environment variable to a Personal Access Token from https://github.com/settings/tokens
-3. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
-4. Update the package versions: `uv run make update-versions NEW_VERSION=v<VERSION>rc1`
-5. Create a PR with the above.
+3. Check that `CHANGELOG.md` is well formatted, ordered in areas, covers all signficant changes, and sub-ordered approximately by user impact & coolness.
+4. Manually remove any entries which were mentioned for in the previous point releases (they will be duplicates!)
+5. Create a new CHANGELOG.md heading to `v<VERSION>rc1`, and create a link at the bottom. Note that you should exactly copy the date and name format from a previous release, as the `build-release.sh` script relies on this.
+6. Update the package versions: `uv run make update-versions NEW_VERSION=v<VERSION>rc1`
+7. Create a PR with the above.
## Releasing -rc1
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.