Publishing excellence #1410
Description
This issue is a catch-all to discuss future potential changes to the publishing flow. Follow up from #1409.
-
Automate the Github release flow, making the
CHANGELOG.mdthe source of truth.Right now the release flow is manual:
- One updates the version in
pyproject.tomlandCHANGELOGand pushes that tomaster - I then usually create a new git tag via Github releases UI, so I can format the release notes, copying the text from CHANGELOG, and sometimes formatting it a bit.
- The CI picks up on the new git tag and publishes package to PyPI.
When we get to v2, our release flow may become more complex if we support both v1 and v2 simultaneously.
At that point it may make sense to also automate the second step, the creation of new git tag and new Github release.
- One updates the version in
-
Pre-releases - Once we get close to v1, it might be necessary to use pre-releases / release candidates (e.g.
1.0.0rc1or1.0.0dev1, see PEP 440 and this SO thread) to do final changes or fixes.At that point, we might want to modify the logic in our documentation workflow, which sets the newly released git tag as the "latest".
Because if I e.g. release a candidate
1.0.0rc1, then the documentation should still point to the previous version (< 0.x.x) as "latest". Only once we actually release1.0.0should the documentation point to that as "latest".