> That being said, the question of "what happens if a feature doesn't > make it in time for the current release schedule's feature freeze?" is > actually more appropriately asked of the community as a whole. I did > propose a feature freeze for Jan 31. If that's not the community > consensus, then we can certainly change it with consensus around a > different plan / schedule. > > With my individual contributor hat on, I feel like a hard feature > freeze is a good thing. We should stick with it. There will be more > releases after this one, and the better we get at following a > time-based schedule the easier and more predictable it will be for > ourselves and our users. I personally don't think that anyone should > feel "rushed" to get something into a particular release. It's better > to get things done *right*. >
So generally speaking - slipping the schedule for a feature inclusion is a completely different release strategy (feature-based releases). IMO we discussed this at length and the benefits of a time-based release far outweigh any short term gain for feature inclusion. Generally speaking, my personal opinion is that features aren't worth slipping the schedule. I expect we'll have enough issues that cause us to slip that we won't need features to add to it. Hard freeze is a good thing. Our release cycles are short for a reason, so that even if you miss a release, the next one isn't too far off, and far better to have a well developed and tested release with fewer features than a more hastily assembled that is potentially more broken. --David
