[GNC-dev] gnucash maint: Replace gitlog2ul.sh with git-release-notes.pl.

[John Ralls]

> On Jun 28, 2019, at 12:41 AM, Geert Janssens <geert.gnucash at kobaltwit.be> 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 <jralls at ceridwen.us>
>> 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