[Bf-committers] Roadmap for 2.5x - 2.6x - beyond

Brecht Van Lommel brechtvanlommel at pandora.be
Sun Mar 13 15:52:25 CET 2011


I think we should make major modifications to the release cycle, to
avoid problems that we've been having with 2.5 and also releases
before that. In my opinion a migration schedule for new features as we
have done before does not work, because it's unpredictable when
developers will be available to work on things, and worse, developers
are blocked a long time waiting.

There's this dynamic which I think we should try to break: unstable
features push back release dates, then after a while, core developers
in other areas get impatient and add another unstable feature, which
agains pushes things back further, while branches get even bigger and
harder to merge.

I strongly believe we should switch to short, fixed release cycles,
and be much more strict in only accepting functionality in trunk that
is reviewed and can be stabilized in a short time. So, this is what I
propose we do:


Releases are unpredictable, it's not clear when they will happen or
when new features can get in. I propose we use a fixed release
schedule, to make it more predictable, ensure regular releases, and to
encourage good development practices.

For example, we could have a 8 week schedule (or even shorter!):
weeks 1-3: new features can be merged
weeks 4-6: stablizing and enhancing
weeks 7-8: critical bugfixes only

If a feature is not stable or not documented by week 7, it gets moved
to the next release (and preferably we find this out earlier). If you
expect a feature is too big to stabilize in the given time, split it


There is the issue of how to do such a release schedule in terms of
branches. Most power users are simply using trunk and not releases, so
having separate branches for development and stable releases is not a
viable option in my opinion. I propose to center everything around
trunk, and let developers use short lived branches while trunk is
locked if they want to.

If we keep the release cycle sufficiently short, developers know they
can merge things soon. I think we should try to avoid branches that
live too long. Features don't get good testing, it's demotivating for
developers, and merging them destabilizes trunk too much. Just split
up things if it doesn't fit the release schedule.

Existing major branches should be merged in pieces if they risk
destabilizing things too much.  If code can't be stabilized in a few
weeks, it simply should not go in trunk, in my experience it is always
possible to split things up.


More information about the Bf-committers mailing list