[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