I think there are couple of different ideas here at play 1) Time to release
2) Quality of the release IMO, the issue that effects most people is the quality of the release. So when someone says that we should slow down the release cycles, I think what they mean is that we should spend more time improving the quality of the releases. Now if there is a process that can ensure the quality of the release, specially the newly added features, I don't think anyone would complain about have quick releases. -- Drew On Dec 20, 2011, at 4:15 PM, Peter Schuller wrote: >> Until recently we were working hard to reach a set of goals that >> culminated in a 1.0 release. I'm not sure we've had a formal >> discussion on it, but just talking to people, there seems to be >> consensus around the idea that we're now shifting our goals and >> priorities around some (usability, stability, etc). If that's the >> case, I think we should at least be open to reevaluating our release >> process and schedule accordingly (whether that means lengthening, >> shorting, and/or simply shifting the barrier-to-entry for stable >> updates). > > Personally I am all for added stability, quality, and testing. But I > don't see how a decreased release frequency will cause more stability. > It may be that decreased release frequency is the necessary *result* > of more stability, but I don't think the causality points in the other > direction unless developers ship things early to get it into the > release. > > But also keep in mind: If we reach a point where major users of > Cassandra need to run on significantly divergent versions of Cassandra > because the release is just too old, the "normal" mainstream release > will end up getting even less testing. > > -- > / Peter Schuller (@scode, http://worldmodscode.wordpress.com)
