[draft] Release plans for 1.9.0?

[Chris Shoemaker]

On Thu, Jan 26, 2006 at 04:17:53PM +0100, Christian Stimming wrote:
> Dear gnucash developers,
> 
> almost two weeks ago I proposed a release schedule for the upcoming 
> unstable 1.9.x release series. See
> https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015658.html
> and http://wiki.gnucash.org/wiki/Release_Schedule
> 
> The goal of the 1.9.x series, starting with 1.9.0, is to provide easier 
> access for testers to a source package. The goal is *not* to be at the 
> "all pieces ported fully to g2" state! Instead, all of these releases 
> will be clearly marked as "work in progress", but I guess we will 
> immediately get a much broader testing audience once we actually start 
> to distribute the unstable tarballs.
> 
> That said, I proposed in that original mail to have the initial 1.9.0 
> release quite soon, namely on next Sunday, January 29th. The question 
> is: What do think needs to be finished before a 1.9.0 release?  

Last time I checked, 'make distcheck' still fails, but 'make check'
passes.  I have some vague impression that this might cause packaging
difficulties.

> Because 
> if there isn't any outstanding issue, we could just as well go ahead and 
> in fact *do* the 1.9.0 release this Sunday. Whoa.

One thing I'd like to include in 1.9.0 is a gnucash-debug script that
runs gnucash under gdb.

> One answer is given by the outstanding bugs in bugzilla which are marked 
> with milestone=1.9.0: 
> http://bugzilla.gnome.org/buglist.cgi?product=GnuCash&target_milestone=1.9.0 
> 
> If you have any more issues, please always add them to bugzilla. 
> http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash If you think 
> these should be fixed before a particular release, mark them with the 
> respective milestone.
> 
> That query currently says there is one more bug that should be fixed 
> before 1.9.0, namely the "Crash on opening 1.8 datafile with renamed 
> reports". But it's not clear whether this has been fixed by Chris and/or 
> cannot be reproduced anymore. If it isn't that much of an issue any 
> longer then maybe we can move it to a later target. If it is still an 
> issue then we need to fix it.

I can reproduce it.  At least, I get the "there had been an error in
the report" message, but not a crash.

> So. What are we going to do? Having a 1.9.0 release this Sunday might 
> sound agressive, but OTOH what do we gain by postponing to some later 
> point in time? If there are particular issues that we think need to be 
> resolved, then I'd propose just the next weekend: Feb 5th. But if there 
> aren't any more issues, then we can just take this weekend...
> 
> We'd still need to point out somebody as the designated release dude who 
> will prepare and upload the tarball. Chris Lyttle did this in 1.8.x. 
> Chris, would you be available to do this for 1.9.x as well or should we 
> point out someone else?
> 
> What do people think?

One issue I've been meaning to raise for a while, but ... better late
than never:  

I think we should totally change the way we produce the NEWS entries.
We should be reporting on significant user-visible changes in the NEWS
file.  I think that we should be making those entries at the _same_
time as the changes themselves.  We can have an accumulator of entries
at the top of the file and then just date and version it at
release-time and start an empty accumulator.

It's tempting to procrastinate but I think it's best to maintain NEWS
as-we-go.  I'll try to commit some entries.

-chris