You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document outlines the process for releasing versions of the form `$MAJOR.$MINOR.$PATCH`.
4
4
@@ -14,31 +14,30 @@ This process also assumes that there will be no minor releases for old major rel
14
14
15
15
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.
16
16
17
-
## Sanity Checks
18
-
Perform these checks before creating a release:
17
+
## Sanity checks
18
+
Perform these checks when reviewing the release PR (see below):
19
19
20
20
1. Ensure `make distcheck` doesn't fail.
21
-
```shell
22
-
./autogen.sh && ./configure --enable-dev-mode && make distcheck
23
-
```
21
+
```shell
22
+
./autogen.sh && ./configure --enable-dev-mode && make distcheck
23
+
```
24
24
2. Check installation with autotools:
25
-
```shell
26
-
dir=$(mktemp -d)
27
-
./autogen.sh && ./configure --prefix=$dir&& make clean && make install && ls -RlAh $dir
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.
38
+
```shell
39
+
tools/check-abi.sh
40
+
```
42
41
43
42
## Regular release
44
43
@@ -47,47 +46,48 @@ tools/check-abi.sh
47
46
* adding a section for the release (make sure that the version number is a link to a diff between the previous and new version),
48
47
* removing the `[Unreleased]` section header, and
49
48
* including an entry for `### ABI Compatibility` if it doesn't exist,
50
-
* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and
51
-
* if this is not a patch release
52
-
* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac` and
49
+
* sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`, and,
50
+
* if this is not a patch release,
51
+
* updates `_PKG_VERSION_*` and `_LIB_VERSION_*` in `configure.ac`, and
53
52
* updates `project(libsecp256k1 VERSION ...)` and `${PROJECT_NAME}_LIB_VERSION_*` in `CMakeLists.txt`.
54
-
2. After the PR is merged, tag the commit and push it:
53
+
2. Perform the [sanity checks](#sanity-checks) on the PR branch.
54
+
3. After the PR is merged, tag the commit, and push the tag:
55
55
```
56
56
RELEASE_COMMIT=<merge commit of step 1>
57
57
git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT
5. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
93
-
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).
91
+
6. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md).
92
+
7. Send an announcement email to the bitcoin-dev mailing list.
93
+
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).
0 commit comments