Roadmap for 2.6, 2.8

Christian Stimming christian at cstimming.de
Wed May 18 14:38:22 EDT 2011


Am Dienstag, 17. Mai 2011 schrieb John Ralls:
> > While playing with all those ideas in my mind, I also came across a very
> > practical question: in what timeframe do we see these refactorings
> > accomplished ?
> > 
> > Based on the development pace for that lead to 2.4, I feel the
> > refactoring may take well over a year. This is in itself no problem and
> > we don't even have to create a fixed schedule.
> > 
> > But at the same time, I would prefer to see more regular major releases
> > in the future. Many distos and large projects are now releasing major
> > versions on a 6 month to 1 year basis. We're not a big project in terms
> > of active contributors of course. But having a shorter release cycle
> > keeps the attention more focussed. And that goes both for developers as
> > the outside world.

Yes, I fully agree here. I'm especially concerned about the newly introduced 
features (in trunk) and the problems if they are not turned into a stable 
release in a somewhat timely manner. The change in user experience when 
updating from 2.4.x to the next 2.6.x will turn into something unpleasant if 
too many new things are in 2.6.x, and also we tend to forget about the new 
features if their introducting was too long ago.

> > So here's a rough proposal of a roadmap:
> > 
> > 2.6 (early 2012 ?)
> > - replace all deprecated library dependencies
> > - full unit test coverage of all core libraries
> > - perhaps some first refactoring of core libraries
> > - perhaps some small additional features

Yes, but I'd prefer this earlier.

Additionally, there should be stable 2.4.x releases every 4-8 weeks. In 
particular, currently a new 2.4.6 would be good due to a significant number of 
fixed bugs.

> > 2.8
> > - full refactoring of all core libraries
> > - serious effort towards an improved gui based on the refactoring
> > - ...
> > 
> > Everything can still change of course, I'm just assessing what is
> > feasible and trying to set some focus. What do you think ?
> 
> Finishing test-writing by the end of the year is reasonable. If the
> refactoring work was limited to cleaning up the object hierarchy and
> making code more maintainable (the sorts of things Martin Fowler writes
> about in his canonical book on the subject), that could be done in a year,
> too. In our case, more extensive surgery is required, so I think we're
> looking at two years (i.e., finish in 2014).

Sounds reasonable. In that case, the refactoring is a useful goal but not a 
useful release schedule setter :-)

> Have you started on the registry rewrite? I'm concerned that that might
> take more than the remaining 7 months in 2011. There's a lot of code in
> there, and it is IIRC the main user of those deprecated libraries.
> 
> When Gnucash migrated to Gtk2, the devs of the day bumped the major rev
> from 1 to 2. Should we do the same again, or wait for the refactored core?

We can bump the major rev as soon as we like. The major version number is 
mainly a marketing instrument. If we can arrive at a gnome3-only 
implementation within the next 12 months, we can use this opportunity to 
switch to 3.x, yes.

Regards,

Christian


More information about the gnucash-devel mailing list