[Bf-committers] Blender Release Cycle

[Campbell Barton]

On Mon, Aug 15, 2011 at 10:40 PM, Sergey I. Sharybin <g.ulairi at gmail.com> wrote:
> Hi, devs!
>
> We've already got thread about release cycles, but it was a bit long and
> seems like there's no final decision made. We've discussed that proposal
> with Campbell and also investigated why we've run into some problems
> with current release. There are some comments which i'd prefer be final
> decision about our release cycle (most people are already ok with it,
> just to make things 100% clear).
>
> Few first weeks of cycle (B-Con 1 and B-Con 2) aren't so critical for
> this discussion and we've already agreed with this levels.
>
> More critical to make work clear in few weeks (1-2) before release (i
> mean before starting commiting new splash/changelogs and so). What is
> needed there:
>
> - Only _critical_ bugs should be fixed. Critical doesn't mean "i can
> make blender crash in few clicks" but it mostly means this bug was
> introduced in current cycle and it stops normal workflow. If this bug
> was present in previous release or if it's not making general usage
> unusable we'd prefer to keep this bug untouched. Fixing such bugs
> wouldn't make real sense on general workflow and if it wasn't noticed in
> previous release then it doesn't annoy artists. But fixing such bugs
> easily produces new bugs which difficult to predict and we wouldn't have
> enough time to test everything.
>
> - We need clear "FREEZE" and "UNFREEZE" AHOYs. If freezing will happen a
> bit earlier -- it's not so critical. But unfreezing should be done quite
> accurate -- when everybody who is familiar with making release would say
> it's ok to unfreeze.
>
> - We'll need tag for every release. It should be created even for
> "initial" release (not corrective release like 'a' or 'b' releases).
> this is needed to make platform maintainers' life more clear. If stopper
> is discovered during archive preparation, fix for this stopper can be
> easily commited to trunk and merged to tag. It'll help a lot for release
> process when most of core/BF developers are offline -- no need to wait
> someone to prepare archive.
>
> - Most probably we'll need guy who is familiar with svn who will make
> tag and solve possible issues of platform maintainers. It shouldn't be
> "constantly" defined developer, prefer to choose one for each release --
> it's needed to be sure he can be available during release.
>
> - So, FREEZE happens, new tag is creating and AHOY could happen. Day or
> two after this normal life of trunk could be restored. But _nobody_
> should commit anything than fixes for stopper/fixes for build
> environment until _official_ unfreeze. Even commit of stylefix could be
> confusing in the future (if more serious problem was discovered, i.e.).
>
> - If 'a' release is needed, we shouldn't re-tag. We should merge fixes
> for _stoppers only_ into tag and do not include fixes for all bugs which
> were made since release. This is a way to avoid 'b' releases.
>
> So, short summary: fix only _really_ critical bugs last week before
> release-related commits; make clear FREEZE/UNFREEZE messages in ML.
> create tag for release just before AHOY, if 'a' release is needed only
> stoppers for previous release (for which 'a' is creating) should be
> ported into tag.
>
> I hope only Campbell/Ton/Brecht make minor changes to this message or
> write things i've forgot to tell about. But again. i don't want this
> message start new discussion thread and i hope it'll be final decision now.
>
> --
> With best regards, Sergey I. Sharybin

Agree with everything *except* for one point,
IMHO 1 week before release only for critical fixes is too long before
release, considering the criteria for these fixes is so strict (which
is a good thing).
I think 3-5 days max would be better.

Otherwise +1 for the proposal.