cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Blockers for 4.0
Date Thu, 21 Jul 2016 14:36:34 GMT
I think this is the right way to think about the problem.

Does 12042, 9424, 8110 cover those bases then?

On Thu, Jul 21, 2016 at 9:02 AM, Sylvain Lebresne <sylvain@datastax.com>
wrote:

> My very own preference would be to actually focus on making 4.0 the release
> where have enough mechanism in place that no further ticket _have to_ wait
> for a major. That means at least making sure CASSANDRA-12042 makes it in,
> adding some proper versioning of schemas and CASSANDRA-8110.
>
> If we had all that in place, I think no other would _have to_ be ready for
> 4.0 as it could then just be delayed to 4.2 (or whenever it's ready).
>
> If we don't do that, I'm willing to take bets that every new major release
> every year will be delayed cause "one more week, X is almost ready and we
> don't want to wait a year to get it in".
>
> On Wed, Jul 20, 2016 at 4:40 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
>
> > The plan of record has been to ship 4.0 in November, 12 months after 3.0.
> > But, there are a number of features that are going to cause backwards
> > incompatibility and if they miss 4.0 will need to wait for 5.0.  Are any
> of
> > these worth delaying 4.0 for?
> >
> > (Currently the plan is to have all of these ready for November, but let's
> > get our backup plan figured out now, just in case.  That way we don't
> have
> > to make the decision at the last minute when everything feels like an
> > emergency.)
> >
> > Some candidates that might be worth delaying the release for:
> >
> >    -  "Birch" trees for the primary key index
> >    <https://issues.apache.org/jira/browse/CASSANDRA-9754>.  Changes the
> >    format of data on disk so automatically in the "dot zero" category.
> >    - Decouple messaging protocol versioning
> >    <https://issues.apache.org/jira/browse/CASSANDRA-12042>.  This would
> >    allow us to change the intra-node protocol on a per-message basis,
> which
> >    gives us more flexibility with compatibility.  Currently any change
> > drops
> >    us into the "no schema changes until everyone is upgraded" world which
> >    effectively rules out making any improvements across tick-tock
> releases.
> >    - Allow dropping COMPACT STORAGE flag
> >    <https://issues.apache.org/jira/browse/CASSANDRA-10857>.  This is
> what
> >    makes it possible to remove the deprecated Thrift support.
> >    - Schema rearchitecture
> >    <https://issues.apache.org/jira/browse/CASSANDRA-9424>.  Can we live
> >    without safe and programatic CREATE and ALTER for another year?
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>



-- 
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder, http://www.datastax.com
@spyced

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