[Bf-committers] Blender Release Cycle

[Michael Fox]

On 16/08/11 14:55, Campbell Barton wrote:
> 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.
>
I never agreed with the 8 week release cycle anyway, as it causes you to 
rush your work resulting in ugly hacked together code and features and 
results also in releases with little substance. Such a cycle works for 
Chrome and FF because they are at each other throats trying to out do 
each other and fix 100s of bugs a day.

This proposal for 8 weeks is foolish, we have always prided ourselves on 
clean(ish) code and well thought out mature features and releases filled 
to the brim with stuff and never put 1 bug above another all bugs are 
the same and the community loves us and loves blender for that as we 
don't belittle their problems.

i know i should have said this earlier but what i say has very little 
meaning anymore like what i said here will be ignored as always