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

[Thomas Dinges]

Hey,
I completely agree with that and be happy that you bring it up now. :)
This 8 weeks release schedule sounds good and doable.

Our main problem was never the amount of new features, it was good
testing and quality. Hopefully this will improve with such a new system.

Very strong +1

Am 13.03.2011 15:52, schrieb Brecht Van Lommel:
> Hi,
> 
> 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:
> 
> 
> RELEASE SCHEDULE
> 
> 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
> up.
>