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(a)gmail.com> wrote:
> 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".