On Fri, 2011-01-14 at 13:11 -0600, Eric Evans wrote: > On Thu, 2011-01-13 at 14:32 -0800, Ryan King wrote: > > # Fixed schedule > > > > We should set a fixed schedule and stick to it. Anything features not > > ready at branch time won't make it and will be disabled in the stable > > branch. > > In general, I agree, if we want a cadence, we're going to have to exert > some pressure to release at an agreed upon time. But, as Jonathan says, > we need to be flexible. > > Even on this project, there have been times when we've put a clock on a > stable release, and had problems with people rushing in poorly tested > changes. >
The Ubuntu project has only slipped (to my knowledge) once in nearly 7 years of 6 month cadence releases. The key is to respect feature freezes, and get everybody on board with slowing or even halting their feature work at those freezes to fix the bugs or even revert things that have panned out poorly. Currently Ubuntu's feature freeze [1] is at week 19 of the 28 week release cycle [2] (they normally are 26 weeks long but 10.10 was shortened for the 10-10-10 release date). Exceptions to the feature freeze can be approved by a board, but must have justification such as when reverting will cause more pain than just finishing it, or that the feature can be disabled by default without breaking other pieces so as not to block the release. I'd recommend that any cadence based release discussion at least examine Ubuntu's implementation and experiences given how successful it has been. The benefits to a large user base are huge. As consumers of Cassandra mature and the coupling with other software becomes tighter, it will be much more important that users can at least have some idea of release timing, even if they can't guarantee that the feature they want goes in. -- 1. https://wiki.ubuntu.com/FeatureFreeze 2. https://wiki.ubuntu.com/NattyReleaseSchedule
