[Bf-committers] Blender Release Cycle

[Campbell Barton]

On Tue, Aug 16, 2011 at 7:52 AM, Michael Fox <mfoxdogg at gmail.com> wrote:
> On 15/08/11 22:40, Sergey I. Sharybin 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.
>>
> I thought this is what we already do, its just in the 2.5 series we have
> become very lazy in these regards, now that 2.5 is final and stable, we
> should really adopt our old methodology again with no set freeze period,
> we aim for a date and set freeze a few days before it, and only release
> if the code is deemed releasable

This goes against the fixed 8 week release cycle, "release when its
ready" might sound good but blender is getting so big that we can
always point at some part
(py-api/input-support/bug-on-some-OS/some-new-library/ffmpeg/sequencer)
and say its not ready *and be right*, but then end up not releasing
even though many bugs _are_ being fixed between releases and useful
improvements made.

With time based releases only consider show-stoppers as new bugs which
were introduced since the last release or anything that makes blender
unstable for common use.

-- 
- Campbell