To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to 8099, in order to not block certain key features, as mentioned. Neutral on any additional nuances.
-Tupshin On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote: > +1 > > On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis wrote: > > *With 8099 still weeks from being code complete, and even longer from > > being > > stable, I’m starting to think we should decouple everything that’s > > already > > done in trunk from 8099. That is, ship 2.2 ASAP with - Windows support- > > UDF- Role-based permissions - JSON- Compressed commitlog- Off-heap row > > cache- Message coalescing on by default- Native protocol v4and let 3.0 > > ship > > with 8099 and a few things that finish by then (vnode compaction, > > file-based hints, maybe materialized views).Remember that we had 7 > > release > > candidates for 2.1. Splitting 2.2 and 3.0 up this way will reduce the > > risk > > in both 2.2 and 3.0 by separating most of the new features from the big > > engine change. We might still have a lot of stabilization to do for > > either > > or both, but at the least this lets us get a head start on testing the > > new > > features in 2.2.This does introduce a new complication, which is that > > instead of 3.0 being an unusually long time after 2.1, it will be an > > unusually short time after 2.2. The “default” if we follow established > > practice would be to* > > > > - > > > > EOL 2.1 when 3.0 ships, and maintain 2.2.x and 3.0.x stabilization > > branches > > > > > > *But, this is probably not the best investment we could make for our > > users > > since 2.2 and 3.0 are relatively close in functionality. I see a couple > > other options without jumping to 3 concurrent stabilization series:* > > > > > > > > * - Extend 2.1.x series and 2.2.x until 4.0, but skip 3.0.x stabilization > > series in favor of tick-tock 3.x- Extend 2.1.x series until 4.0, but stop > > 2.2.x when 3.0 ships in favor of developing 3.0.x insteadThoughts?* > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder, http://www.datastax.com > > @spyced
