Semantic versioning and Changelog

[altsem]

We'll want this in order to start doing releases. Likely we'd need to commit to a commit format.

Investigate and implement tooling around this.

[alerque]

I highly recommend git cliff for this. By default it relies on commits following the conventional commits spec, but it can be customized for other usage as well. Conventional commits has some down sides in my view (e.g. verbosity) as well as any commit scheme introducing some friction. But in my view it is worth it.

Note one common pitfall besides just having to get contributors to do anything regular at all is commiters not understanding that the same changeset might have a different commit message depending on the timeline: a fix: commit only applies if the thing being fixed has previously been released and hence the next release notes should have a bug fix entry, but if the bug being fixed up is not yet released it might be just a chore: or refactor: that (depending on your template) might not even get a mention in release notes. But all caveats aside, I've been using it for a number of projects and having a standard to follow and sticking to it sure makes cutting releases a pleasure.

These is lots of other tooling out there that supports conventional commits, but git cliff is the best changelog generator I've used in production (which is quite a few).

[alerque]

Also I've used commitlint-github-action to lint commit messages in CI which is quite helpful for dealing with PRs and tipping people off to needing to fix this without so much maintainer intervention.

[altsem]

This is great input. Thank you!

[altsem]

Played around with release-plz, but was not happy with the result. Now there's commit linting and a changelog at least :) Will probably want to tweak these settings later.