simple generation of the release news items (r18476 - htdocs/trunk/news - Fix unstable version warning)
stimming at tuhh.de
Fri Dec 11 15:05:18 EST 2009
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.
More information about the gnucash-devel