cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Date Sat, 09 May 2015 22:38:49 GMT
*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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message