Change the CHANGES file format and process of creating the file
The current practice of updating CHANGES file for BIND 9 is:
[<num>]. [<tag>] Description that could
span multiple lines [<#bugnumber>]
Where is incrementing number that doesn't carry any useful information beyond (grep -E '^[[:space:]]*[0-9]+\.' CHANGES | wc -l)
While speaking with @michal about the possibility how to automate the CHANGES file description, I started to doubt what would be the intended audience of current file.
The CHANGES file is a subset of our git log and superset of release notes. It includes all the little details about what has changed in the current release, and I don’t think there’s a user that would be able to checkout git repository, but would look at CHANGES file instead of just doing git log.
I came to two conclusions:
- It is useful to archive the changes in the release tarball generated at the release time
- It makes no sense to update CHANGES file as we go
As for automatically generating the ChangeLog at the release time, I currently see two options:
a) take approach similar to the Linux kernel, simply exporting all the “Merge commits” into a file https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.15.4
b) use a specially formatted commits and helper tool like gitchangelog (https://github.com/vaab/gitchangelog) to create a subset of commits into a meaningful ChangeLog file.
Please comment if you know about a sensible reason why keep updating CHANGES file with the information already contained in the git log, please speak now, otherwise add a comment with your preference for either a) or b). Alternatively, you can propose alternative approach for generating ChangeLog file at the release time.
(This issue isn't about RELEASE NOTES, just about the CHANGES file.)