Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update release procedure #2344

Merged
merged 4 commits into from
Dec 13, 2023
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 27 additions & 10 deletions doc/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,23 +65,40 @@ branch:
## Releasing a patch version

We release patch versions when a crash or a bug is fixed on the main branch and has been
cherry-picked on the maintenance branch.
cherry-picked on the maintenance branch. Below, we will be releasing X.Y-1.Z (where X.Y
is the version under development on `main`.)

- Branch `release/X.Y-1.Z` off of `maintenance/X.Y.x`
- Check the result of `git diff vX.Y-1.Z-1 ChangeLog`. (For example:
`git diff v2.3.4 ChangeLog`)
- Install the release dependencies: `pip3 install -r requirements_minimal.txt`
- Bump the version and release by using `tbump X.Y-1.Z --no-push`. (For example:
`tbump 2.3.5 --no-push`)
- Bump the version and release by using `tbump X.Y-1.Z --no-tag --no-push`. (For
example: `tbump 2.3.5 --no-tag --no-push`. We're not ready to tag before code review.)
- Check the result visually with `git show`.
- Open a merge request to run the CI tests for this branch
- Create and push the tag.
- Open a merge request against `maintenance/X.Y-1.x` to run the CI tests for this
branch.
- Consider copying the changelog into the body of the PR to examine the rendered
markdown.
- Wait for an approval. Avoid using a merge commit. Avoid deleting the maintenance
branch.
- Checkout `maintenance/X.Y.x` and fast-forward to the new commit.
- Create and push the tag: `git tag vX.Y-1.Z` && `git push --tags`
- Release the version on GitHub with the same name as the tag and copy and paste the
appropriate changelog in the description. This triggers the PyPI release.
- Merge the `maintenance/X.Y.x` branch on the main branch. The main branch should have
the changelog for `X.Y-1.Z+1` (For example `v2.3.6`). This merge is required so
`pre-commit autoupdate` works for pylint.
- Fix version conflicts properly, or bump the version to `X.Y.0-devZ` (For example:
`2.4.0-dev6`) before pushing on the main branch
- Freeze the main branch.
- Branch `post-X.Y-1.Z` from `main`.
- `git merge maintenance/X.Y-1.x`: this should have the changelog for `X.Y-1.Z+1` (For
example `v2.3.6`). This merge is required so `pre-commit autoupdate` works for pylint.
- Fix version conflicts properly, meaning preserve the version numbers of the form
`X.Y.0-devZ` (For example: `2.4.0-dev6`).
- Open a merge request against main. Ensure a merge commit is used, because our tooling
depends on distinct commits: one that was tagged with the patch release, and another
that restores the correct version number (the merge commit you made manually). You can
Pierre-Sassoulas marked this conversation as resolved.
Show resolved Hide resolved
defend against trigger-happy future selves by enabling auto-merge with the merge
commit strategy.
- Wait for approval. Again, use a merge commit.
- Unblock the main branch.
- Close the milestone and open a new patch-release milestone.

## Milestone handling

Expand Down