Alternatives to rever for releases

[kenodegard]

Description

We previously documented our process for releasing conda and conda-build with rever (see #541). Both repos have been configured to work the same way (both expect Markdown news files).

Tasks

• [ ] Collect a list of alternative tools.
• [ ] Identify the strengths and weaknesses of each alternative tool.
  • Pay special attention to how OS-agnostic the tools are.
  • The simpler the tool, [probably] the better.

[kenodegard]

Alternative tools

Tool	News Snippets	Format	Git Mailmap	Release PR
rever	✅	RST	✅	❌
towncrier	✅	Agnostic	❌	❌
proclamation	✅	Agnostic	❌	❌
release-please	❌	MD	❌	✅
changine	❌	MD	❌	❌
nextrelease	❌	MD	❌	✅
scriv	✅	Agnostic	❌	❌
blurb
setuptools-changelog
gitchangelog
Chronicler
fastrelease
release-drafter
reno

Thoughts

After researching and looking around, the solution I want to see would be most similar to Google's release-please. There will always be a continuously updated release PR outlining all of the unreleased commits, the updated mailmap, updated changelog derived from news snippets, etc. This process would work great for all regular and optional releases (YY.M.0) but we will need to offer a special process for hotfixes. Hotfixes could perhaps be a manual workflow where we specify the branch name (e.g. v22.7.X) triggering a hotfix release that increments the patch version?

[borchero]

release-drafter has been serving our team very well to organize releases in various projects. With appropriate GitHub Actions in place, it maintains a draft PR with appropriate version and the changelog of all changes since the last release and updates this draft PR after every merge to main. It also supports grouping changes by labels (which can automatically be derived from commit messages via release-drafter as well).

There are two major benefits to this process:

• The next release version can automatically be determined from labels (e.g. a breaking label in any commit to main bumps the major version), allowing everyone to release without thinking about the appropriate next version.
• Prior to actually making a release, the changelog in the draft PR can be manually edited, adding summaries, highlights, ...

A publicly available implementation of this process can be found in this repo.