Proposal: Update archiving process for CHANGELOG.md
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.
-
Keeping only the last minor release information in the
CHANGELOG.md
For example, current release is
13.12.5
. ThenCHANGELOG.md
displays only changes made in between13.12.0
-13.12.5
-
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
. -
Maybe the simple version will consist in rotating the changelog file when it reaches the rendering limit.
Additional questions to consider
- Why do we need
CHANGELOG.md
if we have release posts for each new release? (see example) - Who uses data from
CHANGELOG.md
and what is the main use case? - Should we improve the current way of presenting this data from
CHANGELOG.md
?