Given the recent requests to release a new version of redis-py and my having read this document I started thinking about the release process.I wanted to make release note writing a bit easier, combined with automating pieces of the flow.
[x] Use the release drafter workflow to update release notes for versions
[x] Add python 3.9 to the setup.cfg (just because we should).
[x] Move versioning from the code to setup.cfg. Change redis.__init__.__version__ to get the version from the installed package.
[x] Automate the release to PyPi based on a published release, similar to this, except for setup.py releases.
[ ] Release automation workflow sets the version and commit to the version file to the repo, prior to release.
I'm personally attached to moving release to pyproject.toml, though I understand that might not be something others like. What are your thoughts on both the above, and moving releases to pyproject.toml from setup.py/cfg?
Given the recent requests to release a new version of redis-py and my having read this document I started thinking about the release process.I wanted to make release note writing a bit easier, combined with automating pieces of the flow.
[x] Use the release drafter workflow to update release notes for versions
[x] Add python 3.9 to the setup.cfg (just because we should).[x] Move versioning from the code to setup.cfg. Change
redis.__init__.__version__
to get the version from the installed package.[x] Automate the release to PyPi based on a published release, similar to this, except for setup.py releases.
[ ] Release automation workflow sets the version and commit to the version file to the repo, prior to release.
I'm personally attached to moving release to pyproject.toml, though I understand that might not be something others like. What are your thoughts on both the above, and moving releases to pyproject.toml from setup.py/cfg?