On Mon, Aug 15, 2011 at 10:40 PM, Sergey I. Sharybin <g.ula...@gmail.com> 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. > > -- > With best regards, Sergey I. Sharybin
Agree with everything *except* for one point, IMHO 1 week before release only for critical fixes is too long before release, considering the criteria for these fixes is so strict (which is a good thing). I think 3-5 days max would be better. Otherwise +1 for the proposal. _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers