I like the idea of not having to mess with RELEASE-NOTES-#.## merge conflicts. But I'm not entirely sure about everything in the proposal.
On Thu, May 2, 2013 at 12:30 PM, Krinkle krinklemail@gmail.com wrote:
For more details see Proposal 2 on this page:
https://www.mediawiki.org/wiki/Requests_for_comment/Release_notes_automation...
To avoid wrong entries for bugs that were merely mentioned in the commit message but not fixed in that commit, it becomes more important that we enforce a consistent format. "bug 123" is a mention. "Bug: 123" in footer meta-data indicates the bug was fixed.
So we're changing the semantics of that "Bug" footer already? Instead of being used for searching changesets related to a bug, now it's only for searching changesets actually fixing a bug? And what about changesets that only partially fix a bug? Or bugs where changes to both core and extensions are needed to fix a bug?
We can't use the commit message subject because they aren't always the same as what you want to write in the release notes.
So are we getting rid of the recommended less-than-50-character limit on commit subjects? Or are we assuming that whoever volunteers to clean up the subject-dump will expand on it as necessary?
Mark entries with the relevant labels ("New", "Removed", "Breaking" etc.)
I worry that whoever is doing this for API changes (if it doesn't wind up being me) won't know how we determine "Breaking" for API changes. I.e. "anything that's not backwards-compatible for API users".