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 [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
