[Bf-committers] 2.6 Release Cycle Proposal

Ton Roosendaal ton at blender.org
Fri Jul 29 14:27:16 CEST 2011


Hi,

I'm not convinced such a branching strategy will work for us.

The frustrating aspect of "frozen trunk" is also meant to get focus  
and discipline for everyone to look for a designated period only at  
stability of your work and to go over the bug tracker.

More-over, I prefer to stick to a serious effort to always keep trunk  
stable, at any time. Only on well defined moments (branch mergers,  
patch applying) we can accept a really short while of instability. If  
people do want to continue developing, they can get own branches... or  
we get this git thing sorted out one day :)

What Campbell proposes - to freeze as short as possible - I rather see  
happen then. This whole 'a' release tradition should go away once too.  
Somehow we should attempt to get it right once, before a release!

One of the ways to solve it is by getting our release team (or the  
buildbut) to make more often official builds available. Would be easy  
to at least make a bcon3 build, a bcon4 build, and a release-candidate  
bfore the final.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 29 Jul, 2011, at 9:28, Sergey I. Sharybin wrote:

> Hi,
>
> I'll agree with Campbell. It'll be more convenient for some developers
> (for example, me).
>
> This even can work in such way:
> - Trunk is never frozen
> - Two weeks before release we create new branch (or replacing branch
> from previous release).
> - In trunk usual work could happen.
> - In that separated branch last changes, fixes, stabilization, blah  
> blah
> happens.
> - Some individual fixes can be merged from trunk to that pre-release  
> branch.
> - After release tagging happens based on that pre-release branch.
>
> It's just idea.
>
> And about proposal. It can't totally get us free from corrective
> releases, imo. Sometimes we're updating libraries and time to time
> errors happens when preparing new libraries -- wrong configuration,
> wrong compilation flag, forgotten feature to be included. Such things
> can be handled by corrective releases, but maybe someone got better
> ideas to handle such kind of problems?
>
> Campbell Barton wrote:
>>
>> Hi Thomas, This seems good to me, at least - at least we can go ahead
>> with it and make minor changes if needed.
>>
>> I'd like to raise a topic which isn't addressed in you're proposal.
>>
>> By taking more care to stabilize before release I think we could
>> change how we freeze trunk.
>>
>> Currently we do a release:
>> - freeze before release
>> - release ahoy
>> -  platform maintainers get builds made
>> - official announcement
>> - keep trunk (mostly) frozen for ~1week to see if we need an 'a'  
>> version
>>
>> I worry that we take too much time keeping blender frozen since this
>> can take approx 3 weeks and with the proposal to do better tested
>> releases, this will take longer.
>>
>> If we need to do an 'a' release individualizer fixes could be applied
>> from trunk rather then keeping trunk frozen *just in case* we need to
>> do another release (could branch from the tagged rev and merge only
>> the fixes from trunk).
>>
>> I'd like to know what others think about doing a release and
>> unfreezing soon after ahoy (1-2 days).
>>
>
>
> -- 
> With best regards, Sergey I. Sharybin
>
> _______________________________________________
> 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