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 <sylv...@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 <jbel...@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
