Proposal: Tooling to generate a changelog

[jpmcb]

What I'd like:

Similar to #2206, I'd like to use tooling to generate a changelog.

Currently, the process for maintainers is to look over the changes and PRs since the last release, add them manually to the uber CHANGELOG.md, and then get manual review from other maintainers. This is painful because, often, a sole maintainer does not have all the context to write effective one-liners for each feature, change, or fix.

Instead, we should consider using tooling. Broadly speaking, this is a fairly well solved problem with tools like:

• https://github.com/github-changelog-generator/github-changelog-generator
• https://github.com/conventional-changelog/conventional-changelog
• https://github.com/miniscruff/changie

However, this would also put the onerous of writing a good changelog on each individual contributor. If we used tooling, we would then have to expect each PR to have a good title and well thought out commit message.

Any alternatives you've considered:

It's always possible to generate a one-liner changelog using git:

git log --oneline --decorate

but this is very granular and will include every commit (including merge commits, multi-commits for a single feature, etc.)

[jpmcb]

Another neat one I stumbled upon: https://github.com/googleapis/release-please

[stockholmux]

There is some interesting conversation generation and linting of changing logs over on opensearch.

[stmcginnis]

Just to throw another option on the pile, I've really liked using reno in the past. It's more targeted at release notes versus a change log, but I find that more useful anyway.

Downside is it's written in Python, so it doesn't quite fit with our set of tools. But a Makefile target for it that uses a python container could work. Another option - the git history parsing is really the main complexity. That's all figured out already, so it would be pretty easy to port over and make something like a Reno.rs.