Semantic release with Git tags

[Titus-von-Koeller]

After we're done with the upcoming release, I think setting up the repo to support semantic release based on Git tags would be nice and would make things more efficient. I think this looks pretty promising: semantic release.

Any comments, ideas or opposing views?

cc @akx @matthewdouglas @rickardp @wkpark @younesbelkada

[akx]

Semantic Release is nice in theory, but it will strictly require commits and PRs to use a suitable commit message style so it can figure out whether to create a patch/minor/major version. That may be hard to get people to adhere to.

We already have half of the workflow there to upload wheels to PyPI (in effect releasing a new version to the wild) when a version tag is pushed. Some prefer this to be when a GitHub release is published, which we also already have half of the workflow for.

[rickardp]

I would agree with @akx here. IMHO, automating the actual process of doing the release would be the most important step here (and that is more or less done anyway, I think possibly the last step requires some tuning and secrets need to be added etc).

It is a good practice to follow semantic versioning but automating the version number deduction is only important if releases are entirely automated. The good part of this goal is that it really stresses the need to trust automated tests. Maybe this is an area to focus on first? IMHO the task of hitting the Release button in GH and coming up with a version number is the easy part.