Release Process¶
Release tag schema¶
Release tags should use the vX.Y.Z schema, for example v7.46.1.
The leading v is required for new release tags.
Older releases used REL_X_Y_Z-style tags (for example REL_7_45_7).
These historical tags are kept unchanged and continue to be referenced
from the changelog and from git shortlog invocations such as the one
in step 3 below.
Pushing a vX.Y.Z tag triggers the Draft GitHub Release workflow
(.github/workflows/draft-release.yml), which creates a draft GitHub
Release with automatically generated release notes. Maintainers should
review and edit the draft release before publishing it.
The existing manual Build Wheels workflow
(.github/workflows/cibuildwheel.yml) remains the publishing path for
PyPI and TestPyPI. This first step does not make PyPI publishing
tag-driven.
Release checklist¶
Ensure changelog is up to date with commits in master.
Run
python setup.py authorsand review the updated AUTHORS file.Run
git shortlog REL_<previous release>...and add new contributors missed by the authors script to AUTHORS.Run
python setup.py manifest, check that none of the listed files should be in MANIFEST.in.Check
get_data_files()insetup.pyto see if any new files should be included in binary distributions.Make sure GitHub Actions is green for master.
Create a release branch from master.
Update version numbers in: - Changelog (also record release date) - doc/conf.py - setup.py
Draft release notes, add to RELEASE-NOTES.rst.
Push release branch to GitHub.
Test wheel build using GitHub Actions and fix any issues.
Tag the new version and push to GitHub.
Trigger official wheel build/PyPI push using GitHub Actions.
Merge release branch.
Generate and upload documentation to web site.
Update web site home page.