[Bf-committers] Blender Release Cycle

Sergey I. Sharybin g.ulairi at gmail.com
Mon Aug 15 14:40:36 CEST 2011

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

More information about the Bf-committers mailing list