Guidelines on handling big changelogs #707

Changelogs that are too big become difficult for developers to mantain and for users to refer to, especially when looking for older versions. Considering that versions should not be removed and a changelog should be exhaustive of noteworthy, user-facing changes, simply removing older entries or otherwise collapsing the changelog by condensing old information is not viable. Also, platforms like Github have a limit of length for md files (issue #657).

I think it would be useful to include guidelines on how to handle changelogs that get unyieldly big.

My suggestions would be including an optional Table of Contents section before the Unreleased section and to offer explicit guidelines on how to divide the CHANGELOG into multiple files.

The TOC would make it easier for end-users to navigate longer changelogs:

## Table of Contents

#. [1.0.1](#101---2026-04-15)
#. [1.0.0](#100---2026-04-03)

When dividing a CHANGELOG into multiple files, the files containing older versions should refer to their version range in their name. I'd suggest a name scheme as such: OLDvX.X.X.md, where X.X.X is the last version they cover. For example: OLDv1.0.0.md. The initial version could be easily inferred from the other files. To allow for this, each version should appear ONLY ONCE across all changelog files. Intead of an "Unreleased" section, each file should have a "Newer" (or "Current"?) section with the following text:

## Newer

You are seeing older versions of this project.
For the more recent versions, see the [CHANGELOG](CHANGELOG.md).

the file holding the most recent version should end with an "Older" section linking to the other files like so:

## Older

* [1.0.1-2.0.0](OLDv2.0.0.md)
* [0.1.0-1.0.0](OLDv1.0.0.md)