> On Jun 28, 2019, at 12:41 AM, Geert Janssens <[email protected]>
> wrote:
>
> Op vrijdag 28 juni 2019 01:46:50 CEST schreef John Ralls:
>> Updated via https://github.com/Gnucash/gnucash/commit/58069668
>> (commit)
>> from https://github.com/Gnucash/gnucash/commit/72bdaeef (commit)
>>
>>
>>
>> commit 580696681a3840565012259f57dff9491e28f16a
>> Author: John Ralls <[email protected]>
>> Date: Thu Jun 27 16:43:43 2019 -0700
>>
>> Replace gitlog2ul.sh with git-release-notes.pl.
>>
>> git-release-notes.pl finds the last release on its own and formats
>> the log output separately as text for NEWS and HTML for the
>> announcements.
>>
>>
> Ah, a small advancement in release automation. Nice!
Yeah, I was going to start on parsing out the release notes yesterday and
realized that I could pretty easily automate the bug stuff because of the
consistent summary style. That alone has taken several hours of drudge work. No
more.
That sill leaves figuring out which other commits are worthy of inclusion and
often rewriting them. It'll take more than a perl script to automate that
unless we can come up with some sort of annotation format.
I've included in the new script retrieving notes [1]. They're included in the
output but formatted differently, and offer another way to provide the release
tech with more information about a commit. The advantage here is that they can
be added after the commit without affecting the commit's history. An example
use could be Frank's comment to me on IRC the other day that he had merged
David Cousens's basic debit/credit section without fixing the not very
informative summary. If that had been in early April I wouldn't have a chance
of remembering it now, but putting a note on the commit would now put it in
front of me while I work on the release notes.
Something I'd really like but haven't figured out how to do is to group commits
by feature branch. In general we want a single entry for a new feature and
anyone who wants to know the details can look in the git log for themselves.
An exception to that rule and perhaps the first thing to consider for
annotation and formatting of commit messages is API
addition/deprecation/deletion. I think an "API Changes" section would be a nice
addition to the release notes, but I'm not sure that I can accurately pick them
out from the current free-form commit descriptions.
Regards,
John Ralls
[1] https://git-scm.com/docs/git-notes
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
