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

[Martin Poirier]

Double thumbs up from my end also.

There's a lot to be said about stricter discipline for commits to trunk.

Martin

--- On Sun, 3/13/11, Ton Roosendaal <ton at blender.org> wrote:

> From: Ton Roosendaal <ton at blender.org>
> Subject: Re: [Bf-committers] Roadmap for 2.5x - 2.6x - beyond
> To: "bf-blender developers" <bf-committers at blender.org>
> Received: Sunday, March 13, 2011, 11:08 AM
> Hi Brecht,
> 
> > 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.
> 
> 
> Fully agree! :)
> 
> -Ton-
> 
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org 
>   www.blender.org
> Blender Institute   Entrepotdok 57A 
> 1018AD Amsterdam   The Netherlands
> 
> On 13 Mar, 2011, at 15:52, 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
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>