Getting 2.4 Released - Yes!

[John Ralls]

On Oct 16, 2010, at 12:21 PM, Christian Stimming wrote:

> 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.
> 

Ah, a new Bugzilla trick! Thanks!

I'd say that we (meaning all of the deve) need to change our priorities to getting these four bugs (plus the make check failure Juergen just mentioned) fixed. SQL backends is supposed to be the headline feature for 2.4, so I think that we should make a concerted effort to wring out at least sqlite so that it's part of the release. 

The one that looks like it's fixed is https://bugzilla.gnome.org/show_bug.cgi?id=627831, which comes up third when I follow your link above. If it's actually fixed, why not downgrade it to "normal" and turn off the milestone?

Regards,
John Ralls