[Bf-committers] Avoiding regressions, changes to the release cycle.

[Thomas Dinges]

Sounds like a very good plan, especially to do a real RC, also with 
splash and version bump already. That confused people in the pas as well.

Thanks!

Am 02.08.2013 18:14, schrieb Ton Roosendaal:
> Hi Cam,
>
> Yep we gotta move on. Was suffering jetlag and few days heatwave in Amsterdam :)
>
> Reading all comments, I think there's consensis to:
>
> - Do the usual test build in BCon4 period, just a snapshot of trunk
> - Make a real RC, which is the tagged release branch (with splash, release nr, etc)
> - Do the actual release some weeks after with bugfixes in this branch. (or an RC2, etc, until all is fine).
>
> Which is your 'renaming' proposal, which I didn't get at first. Jetlag :)
>
> Further actions to take:
>
> - Actively remind module owners to at least do serious tests of their areas. It's really part of the responsibility that comes with ownership.
> - Get the regression files upgraded (better ones, not more files!)
> - Investigate various ways for automatic testing
>
> About bi-monthly planning:
>
> I think we're getting a bit release-fatigue now. Pushing a release just because the planning says so isn't very inspiring. We can still do a serious attempt to release as often as possible, but let's base it on a planning that reflects our code work best - branch mergers and refactors should get fair amount of time too.
>
> A useful rule-of-thumb could be to schedule an official new "RC release" two months after the real stable release, which would in practice be a 2.5 to 3 months cycle. We can define this each time on a per-case basis though.
>
> Sounds like a plan?
>
> -Ton-
>
> --------------------------------------------------------
> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org