Proposal for CHANGES change

[chayim]

Given how we now handle CHANGES< and using the release-drafter, we have a chicken and egg issue. The release drafter handles our release notes now. But the merge for a VERSION is responsible for updating the CHANGES file. We can continue to manually update the CHANGES file prior to release, but that's less than ideal. We can ask/continue to ask the community to update the CHANGES file, but that's a different barrier to entry.

Proposal:

• Merges to master update the CHANGES file post-merge. This means a CI run on master, after something has been pushed to master.
• Changes matching some sort of VERSIONING title updates CHANGES, specifically to insert the version number and date, maintaining what we have.
• Optional (I don't personally see the value): We can pre-include a link to the release notes that will be generated for the version.
• Release are just tags, via the drafter. No changes.

Downside

• Some people dislike automatic updates to master (I'm not one of them)
• The formatting present from the release-drafter wont' be present.

@yossigo @michael-grunder WDYT?

[chayim]

@uglide WDYT?

[michael-grunder]

This seems reasonable to me.

I don't mind merges directly to master if it isn't changing any code.

[chayim]

The only kicker is that means master git log is polluted with 'UPDATING CHANGES' type merges. The flip side is that we tried doing this in branches elsewhere, as parts of PRs - and frankly it makes merging awful (almost always a conflict, due to multiple merges). Still - I'm pro

[chayim]

@dvora-h so that you see this