[DRAFT] Proposed release schedule for 1.9.x

[Christian Stimming]

Dear gnucash developers,

the gnome2 porting process is evolving and improving constantly. Over 
the last months we saw a large number of bugs fixed and features 
improved. Some developers (including myself) are already using the 
gnucash-SVN for everyday financial work, although we would probably not 
recommend this for anyone else. The experience and feedback so far are 
quite positive; it seems we are getting closer and closer to an actual 
stable 2.0 codebase.

THAT SAID, I would like to challenge us developers to announce some time 
stamps on our future plans. In particular, I would like to propose a 
release schedule for the pre-2.0.0 releases, which I propose to label as 
1.9.0, 1.9.1 and so forth. The proposed release schedule is available at 
  http://wiki.gnucash.org/wiki/Release_Schedule , can be edited there, 
and is copied below.

  Draft Release Schedule for 1.9.x

This is a draft release schedule for unstable 1.9.x releases of gnucash, 
which will eventually lead to the stable 2.0.0 release of gnome2-based 
gnucash.

Goal for 2.0.0: For the first 2.0.0 release the plan is to finish 
porting those parts of gnucash that have already been started (i.e. new 
windowing system, account tree, commodities tree, etc.), but not to port 
any additional features unless absolutely required.

Purpose of all 1.9.x releases: Any 1.9.x is not yet stable, but is meant 
to provide easier access to the current source code for wider testing. 
Also, at some point in time the 1.9.x series should go into a string 
freeze so that translators can fully concentrate on their translation work.

Requirements of 1.9.x releases:
     * Any 1.9.x has to offer full backward-compatibility of the data 
file. It should always be possible to use a 1.9.x-saved XML datafile 
again with any 1.8.x version. (Note: There was a change at 1.8.?? 
(methinks 1.8.6) to enable correct XML namespace definitions in the 
file; we might drop backward compatibility earlier than that release at 
some point in time.)
     * Any 1.9.x should not crash outright at startup upon loading any 
1.8.x datafile.
           o In particular, bugs like 
http://bugzilla.gnome.org/show_bug.cgi?id=326578 need to be fixed before 
those releases (marked "blocker" in Bugzilla)
           o Also, the problems with slib-3a2 as reported from Debian 
obviously need to be fixed first.

Caveats for testers:

     * Any 1.9.x might crash unexpectedly at any point during runtime. 
If you test some serious work in a 1.9.x release, make sure you hit 
"Save" after ever non-trivial workstep.
     * Keep in mind that features which are not used in everyday work 
might crash unexpectedly at all times. This includes but is not limited 
to: graphical reports, scheduled transaction editor, price editor, 
financial calculator, OFX/QIF/HBCI import.
     * Especially the new features might crash instantly on testing. 
This applies in particular to any of the budget-related features. We may 
always decide to disable such new features for the initial 2.0.0 
release, and re-enable them for a later release branch.

Proposed DRAFT schedule:
All dates are the Sunday of a weekend. It is proposed to have a release 
every three week interval; we might shorten that to shorter intervals 
(every other week, maybe).

     * 1.9.0 January 29th; Initial announcement and call for venturous 
testers
     * 1.9.1 February 19th; bugfixes
     * 1.9.2 March 13th; String freeze; call for translations; call for 
more testers
     * 1.9.3 April 2nd; bugfixes
     * 1.9.4 April 23th; bugfixes
     * maybe? 2.0.0 May 7th; big party at German LinuxTag (cstim will 
probably give a GnuCash presentation there)

This is only a DRAFT and subject to change at all times.

As for additional issues that need to be solved for these 1.9.x releases:
     * Who is going to prepare the tarball ("make dist") and copy it on 
the ftp server?  (I could be volunteering for that, but I don't have FTP 
access. I would certainly volunteer to write the release announcements, 
but that doesn't mean I have to do the other jobs.)

Happy coding everyone! Keep up the good work! We're gonna make it!

Christian Stimming