|
1 | 1 | # Release Process |
2 | 2 |
|
3 | | -1. Open PR to master that |
4 | | - 1. adds release notes to `doc/CHANGELOG.md` and |
5 | | - 2. if this is **not** a patch release, updates `_PKG_VERSION_{MAJOR,MINOR}` and `_LIB_VERSIONS_*` in `configure.ac` |
6 | | -2. After the PR is merged, |
7 | | - * if this is **not** a patch release, create a release branch with name `MAJOR.MINOR`. |
8 | | - Make sure that the branch contains the right commits. |
9 | | - Create commit on the release branch that sets `_PKG_VERSION_IS_RELEASE` in `configure.ac` to `true`. |
10 | | - * if this **is** a patch release, open a pull request with the bugfixes to the `MAJOR.MINOR` branch. |
11 | | - Also include the release note commit bump `_PKG_VERSION_BUILD` and `_LIB_VERSIONS_*` in `configure.ac`. |
12 | | -4. Tag the commit with `git tag -s vMAJOR.MINOR.PATCH`. |
13 | | -5. Push branch and tag with `git push origin --tags`. |
14 | | -6. Create a new GitHub release with a link to the corresponding entry in `doc/CHANGELOG.md`. |
| 3 | +This document outlines the process for releasing versions of the form `$MAJOR.$MINOR.$PATCH`. |
| 4 | + |
| 5 | +We distinguish between two types of releases: *regular* and *maintenance* releases. |
| 6 | +Regular releases are releases of a new major or minor version as well as patches of the most recent release. |
| 7 | +Maintenance releases, on the other hand, are required for patches of older releases. |
| 8 | + |
| 9 | +You should coordinate with the other maintainers on the release date, if possible. |
| 10 | +This date will be part of the release entry in [CHANGELOG.md](../CHANGELOG.md) and it should match the dates of the remaining steps in the release process (including the date of the tag and the GitHub release). |
| 11 | +It is best if the maintainers are present during the release, so they can help ensure that the process is followed correctly and, in the case of a regular release, they are aware that they should not modify the master branch between merging the PR in step 1 and the PR in step 3. |
| 12 | + |
| 13 | +This process also assumes that there will be no minor releases for old major releases. |
| 14 | + |
| 15 | +## Regular release |
| 16 | + |
| 17 | +1. Open a PR to the master branch with a commit (using message `"release: prepare for $MAJOR.$MINOR.$PATCH"`, for example) that |
| 18 | + * finalizes the release notes in [CHANGELOG.md](../CHANGELOG.md) (make sure to include an entry for `### ABI Compatibility`) and |
| 19 | + * updates `_PKG_VERSION_*`, `_LIB_VERSION_*`, and sets `_PKG_VERSION_IS_RELEASE` to `true` in `configure.ac`. |
| 20 | +2. After the PR is merged, tag the commit and push it: |
| 21 | + ``` |
| 22 | + RELEASE_COMMIT=<merge commit of step 1> |
| 23 | + git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" $RELEASE_COMMIT |
| 24 | + git push git@github.com:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH |
| 25 | + ``` |
| 26 | +3. Open a PR to the master branch with a commit (using message `"release: bump version after $MAJOR.$MINOR.$PATCH"`, for example) that sets `_PKG_VERSION_IS_RELEASE` to `false` and `_PKG_VERSION_PATCH` to `$PATCH + 1` and increases `_LIB_VERSION_REVISION`. If other maintainers are not present to approve the PR, it can be merged without ACKs. |
| 27 | +4. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md). |
| 28 | + |
| 29 | +## Maintenance release |
| 30 | + |
| 31 | +Note that bugfixes only need to be backported to releases for which no compatible release without the bug exists. |
| 32 | + |
| 33 | +1. If `$PATCH = 1`, create maintenance branch `$MAJOR.$MINOR`: |
| 34 | + ``` |
| 35 | + git checkout -b $MAJOR.$MINOR v$MAJOR.$MINOR.0 |
| 36 | + git push git@github.com:bitcoin-core/secp256k1.git $MAJOR.$MINOR |
| 37 | + ``` |
| 38 | +2. Open a pull request to the `$MAJOR.$MINOR` branch that |
| 39 | + * includes the bugfixes, |
| 40 | + * finalizes the release notes, |
| 41 | + * bumps `_PKG_VERSION_PATCH` and `_LIB_VERSION_REVISION` in `configure.ac` (with commit message `"release: update PKG_ and LIB_VERSION for $MAJOR.$MINOR.$PATCH"`, for example). |
| 42 | +3. After the PRs are merged, update the release branch and tag the commit: |
| 43 | + ``` |
| 44 | + git checkout $MAJOR.$MINOR && git pull |
| 45 | + git tag -s v$MAJOR.$MINOR.$PATCH -m "libsecp256k1 $MAJOR.$MINOR.$PATCH" |
| 46 | + ``` |
| 47 | +4. Push tag: |
| 48 | + ``` |
| 49 | + git push git@github.com:bitcoin-core/secp256k1.git v$MAJOR.$MINOR.$PATCH |
| 50 | + ``` |
| 51 | +5. Create a new GitHub release with a link to the corresponding entry in [CHANGELOG.md](../CHANGELOG.md). |
| 52 | +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). |
0 commit comments