I think you and Marcus are right: the tension is that while some users want new features faster, others want to keep their cluster as stable as possible. Right now we kind of have the worst of both worlds -- a release cycle slow enough that there's a long wait for new features to stabilize, but fast enough that enterprise types are having to upgrade more often than they're comfortable with.
What if we tried a quicker release cycle, BUT we would guarantee that you could do a rolling upgrade until we bump the supermajor version? So 2.0 could upgrade to 3.0 without having to go through 2.1. (But to go to 3.1 or 4.0 you would have to go through 3.0.) Whether this is reasonable depends on how fast we can stabilize releases. 2.1.0 will be a good test of this. On Tue, Jun 24, 2014 at 8:27 AM, Chris Burroughs <chris.burrou...@gmail.com> wrote: > On 06/17/2014 01:16 PM, Michael Kjellman wrote: >> >> That being said I don’t think i’m alone by identifying the problem. > > > FWIW I'm not doing anything wildly unusual and I've been on a fork for as > long as I've been on 1.2 (and various times before). Almost everyone being > on 1.2 with 3 other equally weighted active branches seems like an obvious > not-great situation for running cassandra or developing. > > I like the idea of shortening the release cycle and LTS style releases and > they feel like the most direct approach. I'm a little wary of more branches > since that could backfire and make the problem worse. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
