On Tue, Jun 24, 2014 at 5:26 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
> > 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.) > I was thinking of something along those lines so I'm in favor of giving that a try. More precisely, I was thinking we could lower the release cycle to 4 month (less feels hard to achieve) but make a "supermajor" only every 2 releases (or less often, though "guarantee that you could do a rolling upgrade" imply that we rigorously test that and I think aiming for 2 release in a row initially is a good start). It's worth acknowledging that this will probably involve a tad more merging work but it feels that increase might be reasonable. -- Sylvain > 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 >
