[Bf-committers] Blender Release Cycle

[Michael Fox]

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 stale, 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