On Tue, Aug 16, 2011 at 7:52 AM, Michael Fox <mfoxd...@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. -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers