Inside Bitcoin
Opening the selected file…
Inside Bitcoin
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1# Release process3This document outlines the process for releasing versions of the form `$MAJOR.$MINOR.$PATCH`.5We distinguish between two types of releases: *regular* and *maintenance* releases.6Regular releases are releases of a new major or minor version as well as patches of the most recent release.7Maintenance releases, on the other hand, are required for patches of older releases.9You should coordinate with the other maintainers on the release date, if possible.10This date will be part of the release entry in [CHANGELOG.md](../CHANGELOG.md) and it should match the dates of the remaining steps in the release process (including the date of the tag and the GitHub release).11It is best if the maintainers are present during the release, so they can help ensure that the process is followed correctly and, in the case of a regular release, they are aware that they should not modify the master branch between merging the PR in step 1 and the PR in step 3.13This process also assumes that there will be no minor releases for old major releases.15We 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.17## Sanity checks19Perform these checks when reviewing the release PR (see below):211. Ensure `make distcheck` doesn't fail.22```shell23./autogen.sh && ./configure --enable-dev-mode && make distcheck24```252. Check installation with autotools:26```shell27dir=$(mktemp -d)28./autogen.sh && ./configure --prefix=$dir && make clean && make install && ls -RlAh $dir29gcc -o ecdsa examples/ecdsa.c $(PKG_CONFIG_PATH=$dir/lib/pkgconfig pkg-config --cflags --libs libsecp256k1) -Wl,-rpath,"$dir/lib" && ./ecdsa30```313. Check installation with CMake:32```shell33dir=$(mktemp -d)34build=$(mktemp -d)35cmake -B $build -DCMAKE_INSTALL_PREFIX=$dir && cmake --build $build && cmake --install $build && ls -RlAh $dir36gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rpath,"$dir/lib",-rpath,"$dir/lib64" && ./ecdsa37```384. Use the [`check-abi.sh`](/tools/check-abi.sh) tool to verify that there are no unexpected ABI incompatibilities and that the version number and the release notes accurately reflect all potential ABI changes. To run this tool, the `abi-dumper` and `abi-compliance-checker` packages are required.39```shell40tools/check-abi.sh41```43## Preparing and tagging a release45If you're going to sign the release, make sure that your default GPG signing key is the [expected one](../SECURITY.md).46You can see your default key by running `echo "test" | gpg --sign --verbose > /dev/null`.48### Regular release501. Open a PR to the master branch with a commit (using message `"release: prepare for $MAJOR.$MINOR.$PATCH"`, for example) that51* finalizes the release notes in [CHANGELOG.md](../CHANGELOG.md) by52* adding a section for the release (make sure that the version number is a link to a diff between the previous and new version),53* removing the `[Unreleased]` section header,54* ensuring that the release notes are not missing entries55(check the `needs-changelog` label on GitHub and also go manually through the list of commits since the previous release), and56* including an entry for `### ABI Compatibility` if it doesn't exist,57* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and,58* if this is not a patch release,59* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac`, and60* updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`.612. Perform the [sanity checks](#sanity-checks) on the PR branch62and attach the output of the [`check-abi`](/tools/check-abi.sh) tool (screenshot of the generated compatibility HTML report) to the PR description.633. After the PR has been merged, tag the commit, and push the tag:64```65RELEASE_COMMIT=<merge commit of step 1>66git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT67git push [email protected]:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH68```694. Open a PR to the master branch with a commit (using message `"release cleanup: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that70* sets `_PKG_VERSION_IS_RELEASE` to `false` and increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac`,71* increments the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt`, and72* adds an `[Unreleased]` section header and a corresponding `[Unreleased]` link at the bottom of [CHANGELOG.md](../CHANGELOG.md).74If other maintainers are not present to approve the PR, it can be merged without ACKs.76### Maintenance release78Note that bug fixes need to be backported only to releases for which no compatible release without the bug exists.801. If there's no maintenance branch `$MAJOR.$MINOR`, create one:81```82git checkout -b $MAJOR.$MINOR v$MAJOR.$MINOR.$((PATCH - 1))83git push [email protected]:bitcoin-core/secp256k1.git $MAJOR.$MINOR84```852. Open a pull request to the `$MAJOR.$MINOR` branch that86* includes the bug fixes,87* finalizes the release notes similar to a regular release,88* increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac`89and the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt`90(with commit message `"release: bump versions for $MAJOR.$MINOR.$PATCH"`, for example).913. Perform the [sanity checks](#sanity-checks) on the PR branch.924. After the PR has been merged, update the release branch, tag the commit, and push the tag:93```94git checkout $MAJOR.$MINOR && git pull95git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH"96git push [email protected]:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH97```985. Open a 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).996. Get the PR merged to ensure that the [CHANGELOG.md](../CHANGELOG.md) file on the master branch is current before announcing the release.101## Creating a tarball and announcing the release1031. Create a tarball and a detached GPG signature covering it, and check that the signature verifies under the expected key.104```105git archive --output "libsecp256k1-$MAJOR.$MINOR.$PATCH.tar.gz" --prefix "libsecp256k1-$MAJOR.$MINOR.$PATCH/" v$MAJOR.$MINOR.$PATCH106gpg --detach-sign "libsecp256k1-$MAJOR.$MINOR.$PATCH.tar.gz"107gpg --verify "libsecp256k1-$MAJOR.$MINOR.$PATCH.tar.gz.sig"108```1092. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).110Attach the tarball and the detached signature.1113. Send an announcement email to the bitcoin-dev mailing list.114## Cleaning up1161. Close the GitHub milestone, and create a new one. Consider moving unresolved issues to the new milestone.1172. Remove the `needs-changelog` label from all merged PRs.
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.