Next release 2.4.1? Branching stable and trunk sooner or later?

[John Ralls]

On Jan 20, 2011, at 12:47 PM, Christian Stimming wrote:

> Developers,
> 
> we should decide when to make our next release 2.4.1, and what should be 
> included. In particular, we need to decide whether a 2.4.1 release should be 
> made from trunk (development) or whether be better want to fork off a 2.4-
> stable branch where this 2.4.1 release is made from.
> 
> Since the 2.4.0 release on 2010-12-20, we have 111 new revisions on trunk. The 
> majority of them are bugfixing and stabilizing which is fine for both trunk 
> and stable branch. But a minor part are completely new features, some of which 
> are a rather isolated part (e.g. a new report), but some of which are more 
> into the core of gnucash, risking new side-effects or bugs that have not yet 
> been found. Some of the commits introduce a few new strings, some even more 
> strings.
> 
> We have been a bit undecided on this issue. Due to our undecidedness some 
> people (and most actively, myself - I pledge guilty on this one :-) started to 
> commit new features already, basically because the features have already been 
> waiting for contribution in my local queue or in bugzilla patches.
> 
> Forking into stable and development (trunk) branches has pros and cons, as 
> always. 
> - Pro: The stable branch has a higher probability not to introduce unexpected 
> bugs. 
> - Con: The merging of stability commits from stable to trunk or vice versa is 
> a PITA with SVN and I want to avoid it because it sucks. (Yes indeed, IMHO 
> this is much easier if one were using git, but we don't, currently.) Hence, 
> with our current SVN repo, creating the two branches now risks diverging so 
> much that we need to abandon the stable branch relatively soon anyway.
> - Con: Because the developer by definition run the trunk version, they won't 
> recognize bugs in stable as quick as they do for bugs in trunk.
> - Con: Only the stable branch will be actively translated, the trunk branch 
> won't have a complete translation until it turns into the next stable.
> 
> So what do we do for 2.4.1 and further "stable" releases? Do we plan a 2.4.1 
> from trunk rather soon, including all new features, and fork after the 2.4.1 
> release for a few subsequent 2.4 stable releases? Are there any more 
> significant changes upcoming which would clearly justify the separation of 
> development and stable? (Not from me - I'm just implementing some minor 
> features here and there, although they do have some minor risk for introducing 
> unwanted side-effects and bugs, as usual.)
> 
> I'd suggest to have a 2.4.1 from trunk rather soon, like, this weekend or the 
> next weekend. There are already a bunch of interesting bugfixes in there. 
> There are still missing bugfixes, but those are missing in 2.4.0 as well, so 
> there's no regression risk here.

There are two things I'd like to get done before we release 2.4.1: I'd like to complete the version control for the sql backend (and I found yesterday that I've a bit more work to do on enforcing read-only on the qofbook) and I'd like to get a test in place for the fast-math bug in libdbi. I understand that the former is new functionality, but it's necessary protection for moving the architecture forward, and we need to have it in 2.4 in order to be able to safely change core in 2.6.

As for branching, well, I feel strongly both ways, for the reasons you give -- though I'm not sure I agree that devs recognizing bugs in one vs. the other is a problem so much as devs fixing bugs in trunk and either not checking stable to see if the bug exists there or not backporting the fix. 

Looking through the svn log I don't see very many feature additions. I see lots of bug fixes, and Phil has been working away with Valgrind cleaning up memory leaks, which is excellent and a very reasonable thing to do in stable, as it improves stability. Another stable-friendly (and very big) job to which I'm going to turn my attention after the two items mentioned above is test coverage. We need to be reasonably confident that passing "make check" really means that we have no regressions (which means going through the bugs, both fixed and not, and writing tests for each one). Committing ourselves to a couple of months of test-writing and bug fixing (they go together rather well) will leave us in a much better position to branch 2.4, because it will be a lot more solid, and in a much better position to start serious refactoring in trunk because we'll be able to immediately see if a refactoring introduced a bug.

Regards,
John Ralls