|
| 1 | +# Releasing |
| 2 | + |
| 3 | +This is notes for the current process of releasing a new PyO3 version. Replace `<version>` in all instructions below with the new version. |
| 4 | + |
| 5 | +## 1. Prepare the release commit |
| 6 | + |
| 7 | +Follow the process below to update all required pieces to bump the version. All these changes are done in a single commit because it makes it clear to git readers what happened to bump the version. It also makes it easy to cherry-pick the version bump onto the `main` branch when tidying up branch history at the end of the release process. |
| 8 | + |
| 9 | +1. Replace all instances of the PyO3 current version with the new version to be released. Places to check: |
| 10 | + - `Cargo.toml` for all PyO3 crates in the repository. |
| 11 | + - PyO3 version embedded into documentation like the README. |
| 12 | + - `pre-script.rhai` templates for the examples. |
| 13 | + - `[towncrier]` section in `pyproject.toml`. |
| 14 | + |
| 15 | + Places where you need to be a bit careful: |
| 16 | + - Add _new_ lines to the netlify `_redirects` file rather than replacing the existing ones. |
| 17 | + - Make sure not to modify the CHANGELOG during this step! |
| 18 | + |
| 19 | +2. Run `towncrier build` to generate the CHANGELOG. The version used by `towncrier` should automatically be correct because of the update to `pyproject.toml` in step 1. |
| 20 | + |
| 21 | +3. Manually edit the CHANGELOG for final notes. Steps to do: |
| 22 | + - Adjust wording of any release lines to make them clearer for users / fix typos. |
| 23 | + - Add a new link at the bottom for the new version, and update the `Unreleased` link. |
| 24 | + |
| 25 | +4. Create the commit containing all the above changes, with a message of `release: <version>`. Push to `release-<BRANCH_VER>` branch on the main PyO3 repository, where `<BRANCH_VER>` depends on whether this is a major or minor release: |
| 26 | + - for O.X.0 minor releases, just use `0.X`, e.g. `release-0.17`. This will become the maintenance branch after release. |
| 27 | + - for 0.X.Y patch releases, use the full `0.X.Y`, e.g. `release-0.17.1`. This will be deleted after merge. |
| 28 | + |
| 29 | +## 2. Create the release PR and draft release notes |
| 30 | + |
| 31 | +Open a PR for the branch, and confirm that it passes CI. For `0.X.0` minor releases, the PR should be merging into `main`, for `0.X.Y` patch releases, the PR should be merging the `release-0.X` maintenance branch. |
| 32 | + |
| 33 | +On https://github.com/PyO3/pyo3/releases, click "Draft a new release". The tag will be a new tag of `v<version>` (note preceding `v`) and target should be the `release-<BRANCH_VER>` branch you just pushed. |
| 34 | + |
| 35 | +Write release notes which match the style of previous releases. You can get the list of contributors by running `nox -s contributors -- v<prev-version> release-<BRANCH_VER>` to get contributors from the previous version tag through to the branch tip you just pushed. (This uses the GitHub API, so you'll need to push the branch first.) |
| 36 | + |
| 37 | +Save as a draft and wait for now. |
| 38 | + |
| 39 | +## 3. Leave for a cooling off period |
| 40 | + |
| 41 | +Wait a couple of days in case anyone wants to hold up the release to add bugfixes etc. |
| 42 | + |
| 43 | +## 4. Put live |
| 44 | + |
| 45 | +To put live: |
| 46 | +- 1. run `nox -s publish` to put live on crates.io |
| 47 | +- 2. publish the release on Github |
| 48 | +- 3. merge the release PR |
| 49 | + |
| 50 | +## 5. Tidy the main branch |
| 51 | + |
| 52 | +If the release PR targeted a branch other than main, you will need to cherry-pick the version bumps, CHANGELOG modifications and removal of towncrier `newsfragments` and open another PR to land these on main. |
| 53 | + |
| 54 | +## 6. Delete the release branch (patch releases only) |
| 55 | + |
| 56 | +For 0.X.Y patch releases, the release branch is no longer needed, so it should be deleted. |
0 commit comments