frost/secp256k1-zkp
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

release process: Style and formatting nits

Browse Source
This commit is contained in:
Tim Ruffing 2023-12-21 17:30:16 +01:00
parent e7053d065b
commit 9fb7e2f156
1 changed files with 27 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
doc/release-process.md
View File

@ -1,4 +1,4 @@
# Release Process # Release process
This document outlines the process for releasing versions of the form `$MAJOR.$MINOR.$PATCH`. 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. 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 ## Sanity checks
Perform these checks when reviewing the release PR (see below): Perform these checks when reviewing the release PR (see below):
1. Ensure `make distcheck` doesn't fail. 1. Ensure `make distcheck` doesn't fail.
```shell ```shell
./autogen.sh && ./configure --enable-dev-mode && make distcheck ./autogen.sh && ./configure --enable-dev-mode && make distcheck
``` ```
2. Check installation with autotools: 2. Check installation with autotools:
```shell ```shell
dir=$(mktemp -d) dir=$(mktemp -d)
./autogen.sh && ./configure --prefix=$dir && make clean && make install && ls -RlAh $dir ./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 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: 3. Check installation with CMake:
```shell ```shell
dir=$(mktemp -d) dir=$(mktemp -d)
build=$(mktemp -d) build=$(mktemp -d)
cmake -B $build -DCMAKE_INSTALL_PREFIX=$dir && cmake --build $build --target install && ls -RlAh $dir 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 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. 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
```shell tools/check-abi.sh
tools/check-abi.sh ```
```
## Regular release ## Regular release
@ -47,12 +46,12 @@ 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), * 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 * removing the `[Unreleased]` section header, and
* including an entry for `### ABI Compatibility` if it doesn't exist, * including an entry for `### ABI Compatibility` if it doesn't exist,
* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and * sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and,
* if this is not a patch release * if this is not a patch release,
* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac` and * updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac`, and
* updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`. * updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`.
2. Perform the [sanity checks](#sanity-checks) on the PR branch. 2. Perform the [sanity checks](#sanity-checks) on the PR branch.
3. After the PR is merged, tag the commit and push it: 3. After the PR is merged, tag the commit, and push the tag:
``` ```
RELEASE_COMMIT=<merge commit of step 1> RELEASE_COMMIT=<merge commit of step 1>
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT
@ -69,7 +68,7 @@ tools/check-abi.sh
## Maintenance release ## 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: 1. If there's no maintenance branch `$MAJOR.$MINOR`, create one:
``` ```
@ -77,19 +76,16 @@ Note that bugfixes only need to be backported to releases for which no compatibl
git push git@github.com:bitcoin-core/secp256k1.git $MAJOR.$MINOR git push git@github.com:bitcoin-core/secp256k1.git $MAJOR.$MINOR
``` ```
2. Open a pull request to the `$MAJOR.$MINOR` branch that 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, * finalizes the release notes similar to a regular release,
* increments `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac` * 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` 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). (with commit message `"release: bump versions for $MAJOR.$MINOR.$PATCH"`, for example).
3. Perform the [sanity checks](#sanity-checks) on the PR branch. 3. Perform the [sanity checks](#sanity-checks) on the PR branch.
4. After the PRs are merged, update the release branch and tag the commit: 4. After the PRs are merged, update the release branch, tag the commit, and push the tag:
``` ```
git checkout $MAJOR.$MINOR && git pull git checkout $MAJOR.$MINOR && git pull
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH"
```
5. Push tag:
```
git push git@github.com:bitcoin-core/secp256k1.git v$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). 6. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).