don't like the practice of requiring that features update a common CHANGELOG file, because it means that now every feature has a merge conflict with respect to every other feature, even if they're otherwise independent
9
7
69
Conversation
Replying to
yup! a much better approach is to make generating a change log at release-time as low-effort as possibleβ¦
1
13
the main problem with this is that getting all contributors to adhere to a commit message format is basically impossible, so my solution is just βeliza manually edits them when merging PRsβ
3
1
10
Replying to
honestly i think this is better, it's much easier for the maintainer to summarize the changes coherently than to try to ask a bunch of disparate contributors to judge how to summarize their change relative to all of the others
3
4
That's what I do for grapheneos.org/releases#chang. I handle merging pull requests for the OS repositories and write a summary of the changes. It's impractical to have a consistent release notes format written by a dozen people especially since many speak English as a 2nd/3rd language.
The canonical copy is in the website repository and the pending changes for the next release are published there as a commented section so people can propose changes to the wording, etc. in advance. It gets reviewed / cleaned up / reordered a bit as part of the release process.