+1. Cassandra has matured a lot lately and more users are relying heavily on it in production. For those users, including us, stability and predictability becomes very important. Not including new and potentially unstable features in maintenance releases is an easy way to decrease risk at a low cost.
/Johan On 11 feb 2011, at 08.35, Gary Dusbabek wrote: > I've been uncomfortable with the amount of features I perceive are > going into our maintenance releases for a while now. I thought it > would stop after we committed ourselves to having a more predictable > major release schedule. But getting 0.7.1 out feels like it's taken a > lot more effort than it should have. I wonder if part of the problem > is that we've been committing destabilizing features into it? IMO, > maintenance releases (0.7.1, 0.7.2, etc.) should only contain bug > fixes and *carefully* vetted features. > > I've scanned down the list of 0.7.1 changes in CHANGES.txt and about > half of them are features that I think could have stayed in trunk. I > think we did this a lot with the early maintenance releases of 0.6 as > well, probably in an effort to get features out *now* instead of > waiting for an 0.7 that was not happening soon enough. We've decided > to pick up the pace of our major release schedule (sticking to four > months). I think maintaining this pace will be difficult if we > continue to commit as many features into the minor releases as we have > been. > > I'm willing to concede that I may have an abnormally conservative > opinion about this. But I wanted to voice my concern in hopes we can > improve the quality and delivery of our maintenance releases. > > Gary.
