Dear Geert, Am Donnerstag, 10. Dezember 2009 schrieb Geert Janssens: > > We also have such a script - the makefile rules for the ChangeLog file > > in the top-level directory do exactly this: It downloads the svn log > > data from the hard-coded revision and formats it into some text file > > by the use of an xslt style sheet. > > I didn't know that. I have looked at the Changelog script. It is > unfortunately of not much help for generating the news files. It outputs > plain text, in a particular Changelog format. > > I played a bit with xslt myself and came up with a script that takes 2 > parameters: $oldversion and $newversion. (eg 2.3.7 and 2.3.8). It will get > all the commits that went into release $newversion since release > $oldversion and outputs a simple html table with this info. This can then > be copy/pasted into the newsfile for $newversion.
thanks for the script - it could be committed in gnucash/util or similar once you've finished working on it. However, the release notes are *not* identical to "svn log": There are plenty of commits which neither need to nor should appear in the release notes, such as "fixed typo" or "added forgotten file". Also, we currently don't have any convention on the maximum size of the commit message (a fact which I currently abuse to copy'n'paste the full discussion into the commit log message, because it is the easiest way for me to look up this discussion later.) In other words: The release notes should clearly contain less text than "svn log", but rather mention those distinct items from a user perspective which have changed. The commit message list of your script is a nice first step to get to such a list, but IMHO it will always need a manual extraction of the useful information. To sum up: The release note list should contain much much less text than the svn log. > I haven't commited this script anywhere just yet. I'm just playing with > ideas. I will attach the example output. It currently contains revision > number, committer and logmessage. Would that be reasonable information to > put in a newsmessage on the website, or do you prefer to keep it as a > bulleted list as it is now ? I clearly prefer a bulleted list, at most with bug numbers where applicable, but no more additional information. BTW if you write a svn commit message and quote a bugzilla bug number, I recommend writing "bug #1234", i.e. with the hash sign in front of the number. Our trac website is set up to turn those numbers (those with hash) into hyperlinks into bugzilla, just as "r123" is turned into hyperlinks to the respective commit log page in trac. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
