Closed
Description
I think with the recent sphinx 8 fixes it woudl be good to make a new release potentially dropping older shinx. Here are the list of things to do for a new release.
Double check for quality-control
- There are no open issues with a
impact: block-release
label
Prepare the codebase for a new version
- Bump
__version__
in__init__.py
- Update our version switcher
.json
file with the new version - Make a release commit:
git commit -m 'bump: 0.1.9 → 0.2.0'
- Push the RLS commit
git push upstream main
- If a release candidate is needed, tick this box when we're now ready for a full release.
Make the release
- Start a new GitHub release
- Call the release the current version, e.g.
v0.2.0
- In the
Choose a Tag:
dropdown, type in the release name (e.g.,v0.2.0
) and click "Create new tag" - In the
Target:
dropdown, pin it to the release commit that you've just pushed. - Generate the automatic release notes, eventually manually specify the previous version (useful when several release candidate have been made)
- Call the release the current version, e.g.
- Confirm that the release completed
- The
publish
github action job has completed successfully in the actions tab. - The PyPI version is updated
- The
- Hide the previous patch version build in the RDT interface if needed.
- Celebrate, you're done!
Activity