-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v0.4.1 release aftermath #1468
Merged
jonasnick
merged 5 commits into
bitcoin-core:master
from
real-or-random:202312-release-aftermath
Jan 16, 2024
Merged
v0.4.1 release aftermath #1468
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
429d21d
release process: Run sanity checks on release PR
real-or-random e7053d0
release process: Add email step
real-or-random 9fb7e2f
release process: Style and formatting nits
real-or-random ad5f589
check-abi: Default to HEAD for new version
real-or-random b37fdb2
check-abi: Minor UI improvements
real-or-random File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
# Release Process | ||
# Release process | ||
|
||
This document outlines the process for releasing versions of the form `$MAJOR.$MINOR.$PATCH`. | ||
|
||
|
@@ -14,31 +14,30 @@ 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 before creating a release: | ||
## Sanity checks | ||
Perform these checks when reviewing the release PR (see below): | ||
|
||
1. Ensure `make distcheck` doesn't fail. | ||
```shell | ||
./autogen.sh && ./configure --enable-dev-mode && make distcheck | ||
``` | ||
```shell | ||
./autogen.sh && ./configure --enable-dev-mode && make distcheck | ||
``` | ||
2. Check installation with autotools: | ||
```shell | ||
dir=$(mktemp -d) | ||
./autogen.sh && ./configure --prefix=$dir && make clean && make install && ls -RlAh $dir | ||
gcc -o ecdsa examples/ecdsa.c $(PKG_CONFIG_PATH=$dir/lib/pkgconfig pkg-config --cflags --libs libsecp256k1) -Wl,-rpath,"$dir/lib" && ./ecdsa | ||
``` | ||
```shell | ||
dir=$(mktemp -d) | ||
./autogen.sh && ./configure --prefix=$dir && make clean && make install && ls -RlAh $dir | ||
gcc -o ecdsa examples/ecdsa.c $(PKG_CONFIG_PATH=$dir/lib/pkgconfig pkg-config --cflags --libs libsecp256k1) -Wl,-rpath,"$dir/lib" && ./ecdsa | ||
``` | ||
3. Check installation with CMake: | ||
```shell | ||
dir=$(mktemp -d) | ||
build=$(mktemp -d) | ||
cmake -B $build -DCMAKE_INSTALL_PREFIX=$dir && cmake --build $build --target install && ls -RlAh $dir | ||
gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rpath,"$dir/lib",-rpath,"$dir/lib64" && ./ecdsa | ||
``` | ||
4. Use the [`check-abi.sh`](/tools/check-abi.sh) tool to ensure there are no unexpected ABI incompatibilities and that the version number and release notes accurately reflect all potential ABI changes. To run this tool, the `abi-dumper` and `abi-compliance-checker` packages are required. | ||
|
||
```shell | ||
tools/check-abi.sh | ||
``` | ||
```shell | ||
dir=$(mktemp -d) | ||
build=$(mktemp -d) | ||
cmake -B $build -DCMAKE_INSTALL_PREFIX=$dir && cmake --build $build --target install && ls -RlAh $dir | ||
gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rpath,"$dir/lib",-rpath,"$dir/lib64" && ./ecdsa | ||
``` | ||
4. 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. | ||
```shell | ||
tools/check-abi.sh | ||
``` | ||
|
||
## Regular release | ||
|
||
|
@@ -47,47 +46,48 @@ tools/check-abi.sh | |
* 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, 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 | ||
* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac` and | ||
* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and, | ||
* if this is not a patch release, | ||
* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac`, and | ||
* updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`. | ||
2. After the PR is merged, tag the commit and push it: | ||
2. Perform the [sanity checks](#sanity-checks) on the PR branch. | ||
3. After the PR is merged, tag the commit, and push the tag: | ||
``` | ||
RELEASE_COMMIT=<merge commit of step 1> | ||
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT | ||
git push [email protected]:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH | ||
``` | ||
3. Open a PR to the master branch with a commit (using message `"release cleanup: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that | ||
4. Open a PR to the master branch with a commit (using message `"release cleanup: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that | ||
* sets `_PKG_VERSION_IS_RELEASE` to `false` and increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac`, | ||
* increments the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt`, and | ||
* 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. | ||
4. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md). | ||
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 | ||
|
||
Note that bugfixes only need to be backported to releases for which no compatible release without the bug exists. | ||
Note that bug fixes need to be backported only to releases for which no compatible release without the bug exists. | ||
|
||
1. If there's no maintenance branch `$MAJOR.$MINOR`, create one: | ||
``` | ||
git checkout -b $MAJOR.$MINOR v$MAJOR.$MINOR.$((PATCH - 1)) | ||
git push [email protected]:bitcoin-core/secp256k1.git $MAJOR.$MINOR | ||
``` | ||
2. Open a pull request to the `$MAJOR.$MINOR` branch that | ||
* includes the bugfixes, | ||
* includes the bug fixes, | ||
* finalizes the release notes similar to a regular release, | ||
* increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac` | ||
and the `$PATCH` component of `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_REVISION` in `CMakeLists.txt` | ||
(with commit message `"release: bump versions for $MAJOR.$MINOR.$PATCH"`, for example). | ||
3. After the PRs are merged, update the release branch and tag the commit: | ||
3. Perform the [sanity checks](#sanity-checks) on the PR branch. | ||
4. After the PRs are merged, update the release branch, tag the commit, and push the tag: | ||
``` | ||
git checkout $MAJOR.$MINOR && git pull | ||
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" | ||
``` | ||
4. Push tag: | ||
``` | ||
git push [email protected]:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH | ||
``` | ||
5. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md). | ||
6. 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). | ||
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). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise, the
HEAD
will be modified, which is not what we want.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure what you meant here, but I believe I fixed it