Proposal: Update archiving process for CHANGELOG.md

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Problem

Gitlab's CHANGELOG.md file updated each release with information about new features, performances and bug fixes. At the end of the major release cycle (ex. 12.10 and 13.12) the file contains thousands of lines and becomes big enough to affect the rendering performance.

Proposal

We already archive old changelogs (see 12.x). So what if we apply the similar strategy not only to major releases but also to minor ones?

There are different ways how it can be implemented.

1. Keeping only the last minor release information in the CHANGELOG.md

   For example, current release is 13.12.5. Then CHANGELOG.md displays only changes made in between 13.12.0 - 13.12.5

2. Keeping last N releases

   The same as above but we extend the releases range. Let's say for last 3 releases it will be 13.9.x - 13.12.x.

3. Maybe the simple version will consist in rotating the changelog file when it reaches the rendering limit.

Additional questions to consider

1. Why do we need CHANGELOG.md if we have release posts for each new release? (see example)
2. Who uses data from CHANGELOG.md and what is the main use case?
3. Should we improve the current way of presenting this data from CHANGELOG.md?