2.6 Release

[John Ralls]

On Dec 27, 2011, at 1:57 PM, Christian Stimming wrote:

> Am Dienstag, 27. Dezember 2011, 22:51:46 schrieb Geert Janssens:
>> At this point I'm actually more inclined to go for plan B, forget the
>> dependency updates on 2.4 and instead focus on getting 2.6 ready and with
>> aqbanking 5.
> 
> I can't add any wisdom as well. Concerning the errors the two of you are 
> reporting, I also don't have any further idea.
> 
> Hence, in order to get a new release up and running, I would indeed also vote 
> for getting a 2.5/2.6 version ready in the rather near future, instead of 
> trying other random bits with the 2.4 branch. Of course, if anyone still finds 
> out what's wrong with the current 2.4 build, this would be fine as well, but 
> on the other hand investing one's time in the new branch is probably the more 
> future-proof investment of time...

I said before I don't have any strong feelings about a 2.6 release. Well, they're growing on me, and they're pretty much opposed.

* Bumping the minor number just because it's been a year is dumb and unprofessional. 

* There are no new features in Gnucash. The Win32 distribution had fallen behind because the shell scripts are so ugly that no one wants to maintain them. It's more up to date now, but the scripts don't suck any less. (Someone has hacked jhbuild to work with MinGW: http://afuera.me.uk/jhbuild-windows/ If that works it would be *way* better than the shell scripts.)

* Any really important bug fixes should be backported, so that shouldn't be a reason to change the minor version.

* Development efforts have really been focussed on 3.0: Geert is working through converting Druids to Assistants and libglade to GtkBuilder. I'm working over the core to make it suitable for a transactional backend. 

* There's no plan.

* There are 4 bugs with a 2.5/2.6 milestone. (There were 6, but I just changed 644244 and 661093 to "future" because the first requires a rewrite of the register code and the second requires full GObjectification (it's caused by our messed-up memory management). Three of them are "reminders" that I wrote to myself; the 4th is 449395 that should have been fixed for 2.4 but just got "kicked down the road".

If we're going to do a 2.6 release we need to set some goals for it and Geert and I should set aside the long-term work and go for those goals. 
* One of the goals can certainly be Geert's credit memos and the accompanying backend changes, but I think we need a bit more than that. 
* Another can be making sure that the SQL backend actually saves everything as soon as an edit is completed. I just fixed the bit for KVP, but the whole program needs to be audited (automated tests would be good!) to make sure that any persistent datum that gets edited is wrapped in the appropriate begin_edit/mark_dirty/commit_edit calls. (There's a better way to do this, of course, but it's part of GObjectification, so if it's going to get fixed before that, it needs to be done the hard way.)

So that's two. ISTM we need 5 or 6 for a 2.6 release series to make sense. It shouldn't be hard to find them in the 868 open bugs.

Frankly, I think it makes way more sense to work on the architectural problems and go 4 years before the next minor release, just like we did last time. If we get the big problems fixed a lot of the smaller ones will get fixed too. That's the "future-proof" way forward.

Regards,
John Ralls