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

[Campbell Barton]

On Sat, Aug 3, 2013 at 2:14 AM, Ton Roosendaal <ton at blender.org> wrote:
> 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 :)

larger change then I anticipated but +1.

> 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

Also good, especially testing if we can manage it.

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

Overall what you suggest is fine but disagree a bit with your rationale.

Doing frequent release isn't about being inspired - its about making
constant improvements available to users and becoming good at keeping
the software usable and stable.
Also, one of the reasons to do frequent releases is that a
merge/refactor can be moved to the next merge-window without it being
a big deal, extending release cycle looses this benefit a bit.

Of course if some large merge pushes the release back a bit, this
can't always be helped but would rather these cases be the exception
and not the rule.

2.68 had no large features merged (as with 2.67) but if you look at
the release log and the accumulated improvements still go towards a
worthwhile release with a short release cycle IMHO.

Personally I feel some release-fatigue, but IMHO this is caused by
accepting large changes then having to frantically fix areas that
break (hangover from 2.67), we should be able to settle down to a
rhythm where blender doesn't becomes very unstable in areas, that we
have to panic and fix before next release.

> Sounds like a plan?

Ok :)

> -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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell