2.6 Release

[John Ralls]

On Dec 28, 2011, at 2:25 PM, Christian Stimming wrote:

> Dear John,
> 
> You are correct that there is "no plan". You are wrong in implying this were a 
> prerequisite to start a new stable series. In this project, often enough the 
> decisions for starting new releases were driven by relatively spontaneous 
> discussions and by what might seem minor reasons to some. I do not agree to 
> this as a valid counter-argument to start a new release cycle.
> 
> Also, I do not agree that there are "no new features." There are, and indeed 
> quite a few, but they are indeed minor from the point of view of the majority 
> of the users. There are several new features around business object management 
> (e.g. customer / vendor overview page; several new reports; invoice 
> duplication). Those features have in common that they're completely 
> uninteresting to the home user. However, in order to make those available to 
> non-english speaking users, they must appear in the stable series because 
> trunk doesn't get translated.
> 
> My main reason for a new stable series is to make life easier for us, the 
> developers. Due to the source code diverging, any non-trivial bugfixing will 
> get increasinly difficult, similar to the large difficulties with the 
> diverging windows builds. To me, this is enough of a benefit to justify a new 
> 2.6 cycle, even if this time there is no "one big new feature" thing as in 
> previous releases.
> 
> By the way, the 2.4 series didn't have that much convincingly new features, 
> did it? It had the SQL backend, but this is completely uninteresting to the 
> majority of the users who are still using an XML file. Also, it switched the 
> HTML engine from gtkhtml to webkit, which was a big deal for us developers, 
> but for the users it was completely uninteresting - almost no visible change 
> for them. I mean, there are times when we have ground-braking new features, 
> but right now there isn't such a time. Even if we completed the gtk3 port, I 
> wouldn't consider that a very user-visible new feature. 
> 
> So from the point of view of the user, it doesn't make a different whether we 
> start 2.6.0 now (and 3.0.0 in 12 months from now), or wait another 6-12 months 
> and start 3.0.0 directly. It will only make our life more complicated due to 
> the more diverged branches.
> 
>> 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 already said: There are a bunch of new features in the business area which 
> are already completed. If it's a matter of listing all of them in order to get 
> "enough reasons" for the 2.6.0, I can surely do so, but for me those are 
> clearly enough new things so that we can claim to bring new features. I think 
> it's well time for a new stable series.

Christian,

You make it sound like you want to release 2.6.0 ASAP with whatever happens to be in trunk on the day of the release.
I'm sure you don't really mean that.

A release plan isn't a "list of features" to "get enough reasons" for a 2.6.0 release. It's a list of features and existing bugs, whether implemented or not, that the project team agrees should be what's going to be in the 2.6.0 release. It guides the testers who use the development (2.5.x) releases, so that they know what to try out, and to write bugs against. It guides developers when reviewing new bugs to decide whether they should be assigned to the 2.6.0 milestone. It tells us when the new release is of sufficient quality for general use, because the features are implemented and tested, and the bugs are fixed or we've agreed to put them off to a later release because we believe that they're not critical. A plan isn't a prerequisite for deciding to do a release,  but it's the first step in any worthwhile release process.

I doubt that either Gtk3 or the engine cleanup will be done in another year unless a lot of help shows up. Going through a development release series  while continuing that work in trunk will push both further out: Time spent getting a release polished up is time not spent on longer-term projects.

By the way, the time between 2.2.0 and 2.4.0 was 42 months (July 2007 to December 2010); it was 22 months between releasing 2.2.0 and the first 2.3 release (May 2009). What's special about a year?

Regards,
John Ralls