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

Tobias Kummer supertoilet at gmx.net
Sun Mar 13 16:20:04 CET 2011


+1 Here, sounds very reasonable!

On 03/13/2011 03:52 PM, Brecht Van Lommel wrote:
> 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.
>
> BRANCHES
>
> 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.
>
>
> Brecht.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list