[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