Sync `CHANGES` file up to 4.6.0? Use as a mainstay?

[tony]

Hi, thank you again for the project! I am re-kindling the request for more attention to be given to maintaining CHANGES. If curated, it can be very beneficial to users downstream.

Follow up to #1868 and #1915

Update to 4.6.0

Right now the CHANGES file is only as far as 4.0.0-beta2, as of #1915 (link)

Use CHANGES as main system?

Thoughts on sticking to CHANGES as a primary release note system?

It is very difficult to link other developers to changes across versions, e.g. 4.0.0 -> 4.6.0 requires (painstakingly) linking individually to 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0, 4.3.0, 4.4.0, 4.5.0, 4.6.0, etc.

For more context, #1868 and https://keepachangelog.com/en/1.1.0/

[chayim]

I'm supportive. Let's re-sync this back in the upcoming 5.x release (very close) if we can. If not, let's immediately do it in the release thereafter.

[akx]

@chayim It's probably time to do this now :)

[petyaslavova]

The changes after version 4.0.0 are available in the repo's release notes, so there is no need to track them in CHANGES file.
The file will exist in the repository to keep the history for earlier versions.
The change is introduced with PR #3645

[tony]

@petyaslavova This approach definitely makes life easier for maintainers, and less overhead is always a win!

However, from a downstream user's perspective, GitHub Releases can be quite cumbersome to work with. I detailed the specific pain points back in #1868 - and if long-term sustainability and accessibility of release notes are priorities for this project, those concerns remain relevant.