Release process automation and improvements

[DomAyre]

@MahatiC @achamayou and I had an interesting discussion yesterday while performing the 2.0.5 release. Mainly focusing on how we can improve our release process (which is already pretty good).

Current process

• When a changelog worthy change is added, update the changelog under the "unreleased" heading (add if not present)
• When we're ready to release, team member makes a PR to change "unreleased" to the next version number
• Once PR is merged, team member creates a tag for the new version (which kicks off all the release CI processes which is great)
• CI prepares a draft release, which a team member reviews and approves

Timing Releases

• For version branches
  • Human decision, for older version branches if there are no fixes then there's no need to make a release.
• Dev releases from main
  • Human decision optionally, if there is a new feature/fix that is worth rolling out to users
  • Fallback regular cadence (e.g. if it's been over one month, and CI is green, prepare release draft for review automatically)

Potential improvements

• Reduce the manual steps required to trigger a release from three (update changelog, create tag, approve) to two (trigger release, approve)
• Have a time-based trigger for dev releases as mentioned above
• Have more of a review process for our changelog

Considerations

• We would like to avoid any improvement relying on ccf-bot, especially to make commits
• We should investigate what other open-source projects do to release their code as this is likely a solved problem

[DomAyre]

That's everything I could remember from the discussions, but I may have missed bits out

[eddyashton]

• Reduce the manual steps required to trigger a release from three (update changelog, create tag, approve) to two (trigger release, approve)

An easy way to do this would be to replace the ## Unreleased section header with what we expect the next version to be, in advance. So after 3.0.4, rather than creating an ## Unreleased section for new entries, we'd create a ## 3.0.5 section. This only gets us part of the way - we often need to patch the CHANGELOG last-minute to clarify/highlight what's actually included in a release. But it would remove a step for some releases. In particular, we can frontload this work with a better review process for the CHANGELOG, but that really needs to be a review of the CHANGELOG on the release branch, which is usually modified by auto-merge PRs.