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

Campbell Barton ideasman42 at gmail.com
Mon Mar 14 23:32:55 CET 2011


+1 to brecht's proposal, big +1 to shorter fixed release cycles.
-1 for discussions on details of point releases, just go with Ton on
this one and focus on real issues :)

On Sun, Mar 13, 2011 at 3:08 PM, Ton Roosendaal <ton at blender.org> wrote:
> 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
>



-- 
- Campbell


More information about the Bf-committers mailing list