-
Notifications
You must be signed in to change notification settings - Fork 1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: Add ABI checking with
check-abi.sh
to the Release Process
- Loading branch information
Showing
1 changed file
with
10 additions
and
4 deletions.
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 |
---|---|---|
|
@@ -37,7 +37,12 @@ gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rp | |
|
||
## Regular release | ||
|
||
1. Open a PR to the master branch with a commit (using message `"release: prepare for $MAJOR.$MINOR.$PATCH"`, for example) that | ||
1. Check the ABI compatibility with the [`check-abi.sh`](/tools/check-abi.sh) tool (installing the `abi-dumper` and `abi-compliance-checker` packages might be required): | ||
```shell | ||
tools/check-abi.sh $(git describe --abbrev=0) master | ||
``` | ||
|
||
2. 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, and | ||
|
@@ -46,19 +51,20 @@ gcc -o ecdsa examples/ecdsa.c -I $dir/include -L $dir/lib*/ -l secp256k1 -Wl,-rp | |
* 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: | ||
|
||
3. After the PR is merged, tag the commit and push it: | ||
``` | ||
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). | ||
|
||
## Maintenance release | ||
|
||
|