On Sun, Mar 13, 2011 at 11:52 AM, Brecht Van Lommel <brechtvanlom...@pandora.be> 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:
+1 > > > 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 > I don't know if this work for all the system/cases, but I am using 'git svn' to keep my local repo update and at the same time keep differents branch to work, is really easy and the merge is also very simple... I know is not the best, but work very well :) > 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. > Agree with this. > 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. > The problem is the "definition" of branch on svn, is painful and not really useful, so I agree with you here, keep "short live" branch and merge as soon is possible. > > 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