2.6 Release

[Phil Longstaff]

Stuff I'm working on:

1) I'm re-doing the preferences to allow an underlying system other than gconf (e.g windows registry, or whatever OS-X uses) and provide same basic prefs interface for global preferences (currently in gconf) vs book preferences (kvp under the book), possibly per-user preferences and per-user-book preferences.

2) I've got various thoughts about the budgeting system since that's what I need to use right now.  There have also been proposals and ideas on the mailing lists that I could incorporate.

Phil


________________________________
 From: Ted Creedon <tcreedon at easystreet.net>
To: 
Cc: "gnucash-devel at gnucash.org" <gnucash-devel at gnucash.org> 
Sent: Wednesday, December 28, 2011 9:56:52 AM
Subject: Re: 2.6 Release
 
Need to update to guile 2.x
Tedc
On Tuesday, December 27, 2011, John Ralls <jralls at ceridwen.us> wrote:
>
> 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
>
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
gnucash-devel at gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel