*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
