What the developer wrote
Authored by Tim Ruffing
release-process: Refactor
What changed, and why it matters
This commit is a simple reorganization of the project's release-process documentation. It renames some sections, splits steps into clearer subsections, and adds minor wording clarifications (for example, reminding maintainers to manually review commits since the last release when writing changelog entries). No code, build scripts, cryptographic logic, or configuration defaults were changed.
No security action needed; this is a documentation-only refactor of internal release instructions.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff only touches doc/release-process.md. It adds whitespace/headings, restructures ‘Regular release’ and ‘Maintenance release’ under a new ‘Preparing and tagging a release’ section, moves the ‘Create GitHub release / send announcement email’ steps into a new ‘Announcing the release’ section, and expands the changelog-check instruction. There are no changes to source files, build system, tests, or release artifacts.
Changed components
doc/release-process.mdInspect captured patch +13 / −8
diff --git a/doc/release-process.md b/doc/release-process.md
index a64bae0..8760c55 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -15,6 +15,7 @@ This process also assumes that there will be no minor releases for old major rel
We aim to cut a regular release every 3-4 months, approximately twice as frequent as major Bitcoin Core releases. Every second release should be published one month before the feature freeze of the next major Bitcoin Core release, allowing sufficient time to update the library in Core.
## Sanity checks
+
Perform these checks when reviewing the release PR (see below):
1. Ensure `make distcheck` doesn't fail.
@@ -39,13 +40,16 @@ Perform these checks when reviewing the release PR (see below):
tools/check-abi.sh
```
-## Regular release
+## Preparing and tagging a release
+
+### Regular release
1. Open a PR to the master branch with a commit (using message `"release: prepare for $MAJOR.$MINOR.$PATCH"`, for example) that
* finalizes the release notes in [CHANGELOG.md](../CHANGELOG.md) by
* adding a section for the release (make sure that the version number is a link to a diff between the previous and new version),
* removing the `[Unreleased]` section header,
- * ensuring that the release notes are not missing entries (check the `needs-changelog` label on github), and
+ * ensuring that the release notes are not missing entries
+ (check the `needs-changelog` label on GitHub and also go manually through the list of commits since the previous release), and
* including an entry for `### ABI Compatibility` if it doesn't exist,
* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and,
* if this is not a patch release,
@@ -64,10 +68,8 @@ Perform these checks when reviewing the release PR (see below):
* adds an `[Unreleased]` section header to the [CHANGELOG.md](../CHANGELOG.md).
If other maintainers are not present to approve the PR, it can be merged without ACKs.
-5. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
-6. Send an announcement email to the bitcoin-dev mailing list.
-## Maintenance release
+### Maintenance release
Note that bug fixes need to be backported only to releases for which no compatible release without the bug exists.
@@ -89,6 +91,9 @@ Note that bug fixes need to be backported only to releases for which no compatib
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH"
git push git@github.com:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH
```
-6. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
-7. Send an announcement email to the bitcoin-dev mailing list.
-8. Open PR to the master branch that includes a commit (with commit message `"release notes: add $MAJOR.$MINOR.$PATCH"`, for example) that adds release notes to [CHANGELOG.md](../CHANGELOG.md).
+5. Open PR to the master branch that includes a commit (with commit message `"release notes: add $MAJOR.$MINOR.$PATCH"`, for example) that adds release notes to [CHANGELOG.md](../CHANGELOG.md).
+
+## Announcing the release
+
+1. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
+2. Send an announcement email to the bitcoin-dev mailing list.
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.