Tooling for Preparing Releases #13
Description
Releases are annoying. We should have suitable tooling to make it easier.
We should also provide Reusable Workflows to combine these in common patterns. But later.
I would like to create a release. To do this, I make a branch for my changes (I often call this something like release or release-v2 or something like that), update the version numbers and changelog on the branch (plus any other work writing summary information, though that might have been done prior to starting the branch). Then I apply a tag to that branch, and ensure that the branch passes all relevant tests (more important when I have complex integration tests that aren't run on every commit). If the tests pass, I make a release by distributing the relevant "release objects" (source archives, signed builds, etc.) to appropriate locations and a set of notifications (usually in a standard form) to relevant channels.
It's often best to create a branch (release-branch), apply the version number updates, do the tag, then merge release-branch back into the main branch. The release branch need not be deleted immediately if there may be further bugfix releases, or could be recreated if that's unexpectedly found to be necessary.
It's usually unwise to have several concurrent release branches unless you've got a very strong customer requirement for it.