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
Copy file name to clipboardexpand all lines: CONTRIBUTING.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -44,7 +44,7 @@ The Contributor Workflow & Peer Review in libsecp256k1 are similar to Bitcoin Co
44
44
45
45
In addition, libsecp256k1 tries to maintain the following coding conventions:
46
46
47
-
* No runtime heap allocation (e.g., no `malloc`) unless explicitly requested by the caller (via `secp256k1_context_create` or `secp256k1_scratch_space_create`, for example). Morever, it should be possible to use the library without any heap allocations.
47
+
* No runtime heap allocation (e.g., no `malloc`) unless explicitly requested by the caller (via `secp256k1_context_create` or `secp256k1_scratch_space_create`, for example). Moreover, it should be possible to use the library without any heap allocations.
48
48
* The tests should cover all lines and branches of the library (see [Test coverage](#coverage)).
49
49
* Operations involving secret data should be tested for being constant time with respect to the secrets (see [src/ctime_tests.c](src/ctime_tests.c)).
50
50
* Local variables containing secret data should be cleared explicitly to try to delete secrets from memory.
To compile optional modules (such as Schnorr signatures), you need to run `cmake` with additional flags (such as `-DSECP256K1_ENABLE_MODULE_SCHNORRSIG=ON`). Run `cmake .. -LH` to see the full list of available flags.
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