+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
