[PROPOSAL] Switch changelog from a single linear to individual files per major.minor version

[stockholmux]

What I'd like: Bottlerocket just released version 1.8.0. 🥳

Looking over the changelog, I noticed it's getting pretty big - 2045 lines right now and it will continue to grow over time. Perhaps it's worth considering moving from the single file to a changelog directory with individual files per major/minor release. Example:

/changelogs
   + changelog-1.8.markdown
   + changelog-1.7.markdown
   + changelog-1.6.markdown
   ...

Note that patches are rolled up into a single file (for example, changelog-1.7.markdown would contain changes for 1.7.0, 1.7.1, and 1.7.2).

This has a few advantages:

• Automation for changelog generation would be easier to build on a per-file basis.
• Linking to a particular version is potentially more predictable (hash linking is currently consistent, but it could easily get messy).
• A project website could render individual files into HTML more easily than all the changes bundled together
• The changelog file would no longer grow ad infinitum.

Any alternatives you've considered:

• A changelog per every version (including patches): Doesn't give a good picture of the features in a release if the most current changelog is a patch.
• A changelog per major version: Would have basically the same downsides as the current changelog but it would be theoretically capped in growth.
• Keep as-is but write a script that slices out each version: This seems like throwing code at a simple problem.

[cbgbt]

One "annoying" thing that could happen is that default file sorting (at least on Linux with ls) will be a bit unfortunate once we hit 1.10, since . sorts earlier than 0, this would cause 1.10 to sort before 1.2 but after 1.0.