[Bf-committers] 2.6 Release Cycle Proposal

[Campbell Barton]

On Thu, Jul 28, 2011 at 4:29 AM, Thomas Dinges <blender at dingto.org> wrote:
> Hey developers,
> this is a first draft of my release cycle proposal. :)
> Please take a look at it and give feedback.
> http://wiki.blender.org/index.php/User:DingTo/ReleaseCycle-Proposal
>
> Idea is to have Cycle after Cycle.
> I hope we get more quality to have a very strict B-Con 4 Level.
> Hopefully this lowers the need for a/b releases. :)
>
> Best regards,
>
> --
> Thomas Dinges
> Blender Developer, Artist and Musician
>
> www.dingto.org

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).

-- 
- Campbell