How about naming it 2.9 as a development preview version before 3.0? If this version and 3.0 are close in functionality, it is not a good idea that the two version number have a huge difference. And after 3.0 being shipped, I think we should stop maintaining this version because of the similarity with 3.0 and still maintain 2.1.x since 2.1.0 was shipped 8 months ago and just have a "maybe product ready" version 2.1.5.
2015-05-10 20:17 GMT+08:00 <tups...@tupshin.com>: > 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 > -- Thanks, Phil Yang
