Situation

The current release process is described in the file release-procedure.md. It's a bit of cumbersome as a lot of things needs to be done manually.

Some ideas were already described in #186, this is specific for releases.

Proposed Solution

A GitHub Action seems a good method for this task. Some ideas what our Action could do:

• start the release process when a) a tag is created with adheres to the semantic version, or, b) a branch release/VERSION is merged into master.
  (not sure which one of this will be better or more feasible)
• Verify if a branch release/VERSION matches with the __version__ variable in semver.py?
• Verify if the CHANGELOG.rst contains the correct version string?
• Maybe use the branch release/VERSION to publish it to the TestPyPI first.
• When the branch release/VERSION is merged into master (and only then!), do:
  • deploy it to PyPI
  • create a tag (and use the content of the CHANGELOG.rst?)
  • update the "Releases" tab on our GitHub repo page
  • ...

It's just a collection of rough ideas. I need to try it what's possible and what is more difficult.

@scls19fr If you have more ideas or disagree with the above, just let me know so I can tailor this Action for our specific use case. :-)

Hint:
I will try it out in my fork first so this repo will be kept clean.

See also

Possible GH Actions to investigate further:

• create-release action
• pypi-publish
• deploy-pypi
• Publishing package distribution releases using GitHub Actions CI/CD workflows
• GitHub Actions: Manual triggers with workflow_dispatch (added on 2020-11-15, found by @tlaferriere, thanks!)