Source GitHub Release description from CHANGELOG.md

[guseggert]

Currently we use Unified CI for tagging releases based on version.json, but we'd like to minimize the effort for cutting releases so that we can cut them more frequently.

So I propose we instead cut releases using https://github.com/pl-strflt/changelog-driven-release. Basically the workflow would look like:

• Accumulate changes in the [Unreleased] section of the CHANGELOG
  • These should be added as commits are added, and the CHANGELOG update should happen as part of the PR for a feature
    • CI enforcement of this is tracked here: Enforce changelog updates in CI #267
• When ready to release, change [Unreleased] to [vX.Y.Z] YYYY-mm-dd, which is then detected by CI as a release and results in a new tag and a GitHub release with the changelog contents in the release notes.

Other requirements:

• We currently run Kubo tests for each release, until enough are moved into Boxo, so we need to run releases on a release-vX.Y.Z branch and merge into release which should trigger the release. This way we don't have to "freeze" main while we do a release. Once the release is complete, merge release into main (which should NOT trigger a release). This is different than most folks, who just merge to main which triggers a release based on the tip of main...we do NOT want this behavior.
• We love all the checks that Unified CI does for releases and would like to keep them (release checker workflow, which runs gorelease et al to verify the release version, call out breaking changes, etc.)

[BigLep]

Thanksk @guseggert . I like it.

One question: will there be validation that the [vX.Y.Z] in the changelog is appropriate (basically that we aren't doing a patch release when we should be doing a minor release at the minimum)? I believe we got that validation with the version.json method.

[guseggert]

Good callout I added that to the list of requirements

[galargh]

We met with Gus and talked about this some more. Quick summary, we decided not to try and make changelog-driven-release fit boxo's needs as it would require too much work and adjustment when it comes to workflows engineers are used to. Instead, we're going to focus on:

1. Ensuring changelog is always up to date through automation - Enforce changelog updates in CI #267
2. Expanding Unified CI in such a way that would allow us to source GitHub release description from CHANGELOG.md

This issue will cover the 2nd point.