+1 to brecht's proposal, big +1 to shorter fixed release cycles. -1 for discussions on details of point releases, just go with Ton on this one and focus on real issues :)
On Sun, Mar 13, 2011 at 3:08 PM, Ton Roosendaal <t...@blender.org> wrote: > Hi Brecht, > >> I strongly believe we should switch to short, fixed release cycles, >> and be much more strict in only accepting functionality in trunk that >> is reviewed and can be stabilized in a short time. > > > Fully agree! :) > > -Ton- > > ------------------------------------------------------------------------ > Ton Roosendaal Blender Foundation t...@blender.org www.blender.org > Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands > > On 13 Mar, 2011, at 15:52, Brecht Van Lommel wrote: > >> Hi, >> >> I think we should make major modifications to the release cycle, to >> avoid problems that we've been having with 2.5 and also releases >> before that. In my opinion a migration schedule for new features as we >> have done before does not work, because it's unpredictable when >> developers will be available to work on things, and worse, developers >> are blocked a long time waiting. >> >> There's this dynamic which I think we should try to break: unstable >> features push back release dates, then after a while, core developers >> in other areas get impatient and add another unstable feature, which >> agains pushes things back further, while branches get even bigger and >> harder to merge. >> >> I strongly believe we should switch to short, fixed release cycles, >> and be much more strict in only accepting functionality in trunk that >> is reviewed and can be stabilized in a short time. So, this is what I >> propose we do: >> >> >> RELEASE SCHEDULE >> >> Releases are unpredictable, it's not clear when they will happen or >> when new features can get in. I propose we use a fixed release >> schedule, to make it more predictable, ensure regular releases, and to >> encourage good development practices. >> >> For example, we could have a 8 week schedule (or even shorter!): >> weeks 1-3: new features can be merged >> weeks 4-6: stablizing and enhancing >> weeks 7-8: critical bugfixes only >> >> If a feature is not stable or not documented by week 7, it gets moved >> to the next release (and preferably we find this out earlier). If you >> expect a feature is too big to stabilize in the given time, split it >> up. >> >> BRANCHES >> >> There is the issue of how to do such a release schedule in terms of >> branches. Most power users are simply using trunk and not releases, so >> having separate branches for development and stable releases is not a >> viable option in my opinion. I propose to center everything around >> trunk, and let developers use short lived branches while trunk is >> locked if they want to. >> >> If we keep the release cycle sufficiently short, developers know they >> can merge things soon. I think we should try to avoid branches that >> live too long. Features don't get good testing, it's demotivating for >> developers, and merging them destabilizes trunk too much. Just split >> up things if it doesn't fit the release schedule. >> >> Existing major branches should be merged in pieces if they risk >> destabilizing things too much. If code can't be stabilized in a few >> weeks, it simply should not go in trunk, in my experience it is always >> possible to split things up. >> >> >> Brecht. >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers