Getting 2.4 Released - Yes!

[Christian Stimming]

Dear John,

I completely agree. It's been two months already since the last test release, 
and we didn't see any significant progress in the last fields that were 
expected to be fixed before 2.4.0. 

Am Saturday 16 October 2010 schrieb John Ralls:
> What needs to be done to make the next test release a "release candidate"
> that we can safely recommend to ordinary users that they can try it out
> without risking their data? (FWIW, I've been using 2.3.15 regularly
> without incident, but there are lots of features that I don't use.)

I've been using it as well, and I've explained on this list before (and on 
gnucash-de) that I consider 2.3.15 (but excluding the SQL backends, i.e. still 
with XML file store) to be ready for normal everyday use.

> There are two bugs with priority higher than normal

This isn't the criterion for the upcoming 2.4.0 release. Instead, the 
"milestone" is the criterion. See:

https://bugzilla.gnome.org/buglist.cgi?product=GnuCash&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.4.0

The topmost issue there is already fixed, the bug is only left open because of 
ongoing additional patch discussion. This leaves us with 5 open issues, and

> Database backend locking is one of them,

Yes. IMHO this is the single main blocker preventing us from a release with 
the new SQL backends enabled.

Personally, I'd even suggest we should delay the activation of the sql 
backends to the general public for more releases, i.e. disabling them for the 
release time, then pushing 2.4.0 out the door (with still only xml file 
storage), then enabling it again for SVN trunk and further "unstable" 
releases. I mean, except for the buzzword "SQL" the benefit to the user of our 
current sql backend isn't too significant. Hence, we can also admit to 
ourselves this features doesn't have much to gain (because of the limited 
benefit), but plenty to loose (because of the ongoing potential of unnoticed 
data loss in features which are much less commonly used). This is my view on 
how to enable a 2.4.0 stable release, given our *current* development 
priorities as visible from the SVN commits.

Regards,

Christian