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