Release action

[simonrw]

I am starting to build a release github action for maintainers (currently @cjordan and me) so that

1. we are not reliant on users computers to do releases, and
2. the process is codified so that there are no mistakes.

I have done all of the releases in the past, but that may need to change. I want to open the floor up to other contributors.

The current release process currently depends on the crate being released, but generally is as follows:

1. Bump the version.
2. (fitsio only) Update the README.md for any references to the fitsio version - this is checked in tests, so must be correct.
3. Update the changelog - we follow https://keepachangelog.com, however I am not set on how we represent the different crates in this workspace. Some background: this workspace was created after I had been developing fitsio for a while, and as such most of the "meta" files refer only to fitsio but there are now other crates.
4. Add a git tag, depending on the crate, specifically: <crate>-<version>
5. Publish to crates.io

Ideally this should all happen in a PR, triggered by the new workflow, unfortunately it is not currently fully automated - points 1 and 2 can be done in the PR, but the rest is not yet implemented, or cannot be implemented (the changelog).

I am interested to learn more about how we can continue automating this process. In general:

• I am not a fan of extracting a changelog from commits/PRs - I think the changelog should be written by a human, but I'd like to enforce that the changelog is accurate before closing any release PR
• points 4 and 5 should really be done when the release PR is merged, otherwise there is a risk that they either won't happen, or they happen multiple times (not possible with cargo publish).

cc @cjordan

[cjordan]

So I've been thinking about a lot of this for my own projects. As there's no clear perfect answer, I've merely put up with doing things manually, although recently I've made a "cargo publish" CI step if the tests pass the commit is a version tag on the main branch.

Again, imperfect, but I've been trying to be good about updating the changelog with each commit, and typically from the perspective of "what do the users want to see". It's the sort of thing that can distract from coding, but I don't think it's overly onerous. Changing READMEs can be quite onerous, although I don't think it's possible to automate this as (emergent AI tools notwithstanding) only a human knows how to disseminate the changes. I also believe if anyone was really interested in seeing what changes happened, it's easy to match up the changelog message with commit.

I'm not sure how to automatically bump versions. There is a tool "cranko" that may be useful, but I'm still yet to fully understand what it does.