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

[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



On 1 Aug, 2013, at 21:41, Campbell Barton wrote:

> Any conclusion to this thread?
> 
> Ton, you responded to a separate issue which Brecht raised (which is a
> valid discussion), but I'm concerned that disagreement on larger
> changes to the release-cycle get in the way, the topic gets dropped -
> then we don't make smaller (IMHO common sense) changes like the one I
> originally proposed.
> 
> It's mailing-list version of `Embrace, extend and extinguish`
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers