From: Kimmo Varis <kimmov@wi...> - 2008-05-21 17:51:27
we've decided to change our development model with WinMerge development.
Reasons are simple:
- it takes almost an year for us to get a new stable release out
- trunk and stable branch diverge (sometimes) fast and merging isn't
easy, we may even need totally different patches for trunk and branch
- testing coverage of stable branch is poor, as we merely merge patches
from trunk (sometimes even without trunk coverage, see earlier point)
- we can't take large patches near stable releases, causing long delays
and frustation for people submitting patches
New model consists of two development lines:
- trunk as "working space"
- development branch as a branch heading for next stable release
The trunk will become easier to get patches in for regular developers.
Most smaller patches can be committed without review. This saves a lot
of time as there is no need to wait for days for the review. And I want
this to shift into building features and fixes incrementally, using
smaller patches. Than trying to get big patches working, reviewed and
merged without problems. So it is better to commit 10 small patches,
each making sense as their own.
The development branch is "always stable" branch. It should get only
tested patches by merge from trunk. Usually there should not be patches
committed directly to the branch. The development branch simply cannot
break or have regressions. If the patch causes problems, it gets
reverted and should be fixed in trunk before it can be merged to the
The patch also must be accepted to the branch. That is I or somebody
else must say the patch is ok for the next release. If the patch doesn't
get accepted, it means it needs more work and either can be ready later,
or should wait for the following release (branch). But in this model it
means few months, not over an year of waiting.
Generally development branch will be created (soon) after stable
release, from current trunk. If there are problematic patches, they are
- work in trunk, commit small patches with meaningfull commit messages
- once the feature/fix is ready, create new patch to patch tracker,
creating "normal" patch or just referring to revision numbers used
- somebody reviews the patch for branch
- merge the patch to branch
Development branch should be thought as our current stable branches.
Most work has already been done earlier in the trunk, and only "safe"
changes get into branch once it is created.
I've written a new page to the development wiki:
I'll create the branch for 2.9/2.10 development in next few days. I'm
really hoping it works and we'll have stable releases every 4-5 months.