You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Jonathan Ellis <jb...@gmail.com> on 2016/07/20 14:40:09 UTC
Blockers for 4.0
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
Re: Blockers for 4.0
Posted by Aleksey Yeschenko <al...@apache.org>.
3.10 most likely.
--
AY
On 21 July 2016 at 01:28:13, Jake Luciani (jakers@gmail.com) wrote:
Will that be in 3.x or 4?
Re: Blockers for 4.0
Posted by Jake Luciani <ja...@gmail.com>.
Will that be in 3.x or 4?
On Wed, Jul 20, 2016 at 8:20 PM, Aleksey Yeschenko <al...@apache.org>
wrote:
> I don’t think so, b/c
> https://issues.apache.org/jira/browse/CASSANDRA-12142 will allow us to
> develop them incrementally.
>
> --
> AY
>
> On 20 July 2016 at 22:03:37, Jake Luciani (jakers@gmail.com) wrote:
>
> Also, anything related to native protocol v5
> https://issues.apache.org/jira/issues/?jql=labels%20%3D%20protocolv5
>
--
http://twitter.com/tjake
Re: Blockers for 4.0
Posted by Aleksey Yeschenko <al...@apache.org>.
I don’t think so, b/c https://issues.apache.org/jira/browse/CASSANDRA-12142 will allow us to develop them incrementally.
--
AY
On 20 July 2016 at 22:03:37, Jake Luciani (jakers@gmail.com) wrote:
Also, anything related to native protocol v5
https://issues.apache.org/jira/issues/?jql=labels%20%3D%20protocolv5
Re: Blockers for 4.0
Posted by Jake Luciani <ja...@gmail.com>.
Also, anything related to native protocol v5
https://issues.apache.org/jira/issues/?jql=labels%20%3D%20protocolv5
On Wed, Jul 20, 2016 at 11:30 AM, Jason Brown <ja...@gmail.com> wrote:
> forgot to mention that 8457 changes the internode messaging protocol, so
> needs to fall on a major version boundary.
>
> If 8457 does go forward, and CASSANDRA-8911 (mutation-based repair) does
> *not* happen, we'll need something like CASSANDRA-12229 (to support
> streaming under the non-blocking/netty model due to the changes introduced
> in 8457, which are documented in ticket)
>
> On Wed, Jul 20, 2016 at 8:16 AM, Aleksey Yeschenko <al...@apache.org>
> wrote:
>
> > I’d strike CASSANDRA-10383 off the list - there is no way it’s a blocker
> > for anything.
> >
> > As for 9424, unless I die unexpectedly *and* nobody else picks up the
> > work, it should be fine for Nov.
> >
> > Don’t see anything missing from the list.
> >
> > --
> > AY
> >
> > On 20 July 2016 at 15:59:34, Jason Brown (jasedbrown@gmail.com) wrote:
> >
> > CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review
> >
> > On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jb...@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
> > >
> >
>
--
http://twitter.com/tjake
Re: Blockers for 4.0
Posted by Jason Brown <ja...@gmail.com>.
forgot to mention that 8457 changes the internode messaging protocol, so
needs to fall on a major version boundary.
If 8457 does go forward, and CASSANDRA-8911 (mutation-based repair) does
*not* happen, we'll need something like CASSANDRA-12229 (to support
streaming under the non-blocking/netty model due to the changes introduced
in 8457, which are documented in ticket)
On Wed, Jul 20, 2016 at 8:16 AM, Aleksey Yeschenko <al...@apache.org>
wrote:
> I’d strike CASSANDRA-10383 off the list - there is no way it’s a blocker
> for anything.
>
> As for 9424, unless I die unexpectedly *and* nobody else picks up the
> work, it should be fine for Nov.
>
> Don’t see anything missing from the list.
>
> --
> AY
>
> On 20 July 2016 at 15:59:34, Jason Brown (jasedbrown@gmail.com) wrote:
>
> CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review
>
> On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jb...@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
> >
>
Re: Blockers for 4.0
Posted by Aleksey Yeschenko <al...@apache.org>.
I’d strike CASSANDRA-10383 off the list - there is no way it’s a blocker for anything.
As for 9424, unless I die unexpectedly *and* nobody else picks up the work, it should be fine for Nov.
Don’t see anything missing from the list.
--
AY
On 20 July 2016 at 15:59:34, Jason Brown (jasedbrown@gmail.com) wrote:
CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review
On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jb...@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
>
Re: Blockers for 4.0
Posted by Robert Stupp <sn...@snazy.de>.
There’s also:
CASSANDRA-10520 Compressed writer and reader should support non-compressed data (changes sstable format)
CASSANDRA-10383 Disable auto snapshot on selected tables (changes schema)
—
Robert Stupp
@snazy
> On 21 Jul 2016, at 00:59, Jason Brown <ja...@gmail.com> wrote:
>
> CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review
>
> On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jb...@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
>>
Re: Blockers for 4.0
Posted by Jason Brown <ja...@gmail.com>.
CASSANDRA-8457 - nio MessagingService. Patch is up and awaiting review
On Wed, Jul 20, 2016 at 7:40 AM, Jonathan Ellis <jb...@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
>
Re: Blockers for 4.0
Posted by Jonathan Ellis <jb...@gmail.com>.
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 <sy...@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 <jb...@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
Re: Blockers for 4.0
Posted by Sylvain Lebresne <sy...@datastax.com>.
On Thu, Jul 21, 2016 at 5:40 PM, Aleksey Yeschenko <al...@apache.org>
wrote:
> We don’t need to block 4.0 on #8110.
>
> What we need is to block those sstable-format related tickets on *either*
> #8110 *or* 4.0.
>
You're right, I kind of listed the ticket a bit quickly.
>
> #8110 itself can go anywhere in 3.x or 4.x.
>
> --
> AY
>
> On 21 July 2016 at 15:38:58, Jason Brown (jasedbrown@gmail.com) wrote:
>
> Sylvain,
>
> In the large, yes, that is the best "have enough mechanism in place that no
> further ticket _have to_ wait for a major", but many of the tickets we are
> talking about makes changes to things we've all agreed can *only* happen at
> majors, as per the
> http://wiki.apache.org/cassandra/CompatibilityGuarantees
> (changing the internode protocol, for instance).
>
> if we're willing to trade on those Guarantees, then sure, majors are just
> bike shedding the version numbers, but I suspect we don't want to do that
> ;)
>
> That being said, I completely understand the frustration of "one more week,
> X is almost ready and we don't want to wait a year to get it in". I offer
> two points, though:
> 1) This is an open source project, with no real business requirements to
> ship any version by any specific date. We want to ship often enough to be
> relevant as a project/product, of course, but there's no financial or
> business requirement to do so.
> 2) We could have better planning as to what we actually want to ship in a
> "version", or at least have some agreed upon mid- to long-term roadmap.
> This would help focus the calendar and the project. Currently, it's largely
> willy-nilly as to what ships when, and while tick-tock has introduced
> regularity wrt release dates, there's not much that shapes what goes in
> those releases.
>
> My two cents,
>
> -Jason
>
>
>
> On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sy...@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 <jb...@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
> > >
> >
>
Re: Blockers for 4.0
Posted by Aleksey Yeschenko <al...@apache.org>.
We don’t need to block 4.0 on #8110.
What we need is to block those sstable-format related tickets on *either* #8110 *or* 4.0.
#8110 itself can go anywhere in 3.x or 4.x.
--
AY
On 21 July 2016 at 15:38:58, Jason Brown (jasedbrown@gmail.com) wrote:
Sylvain,
In the large, yes, that is the best "have enough mechanism in place that no
further ticket _have to_ wait for a major", but many of the tickets we are
talking about makes changes to things we've all agreed can *only* happen at
majors, as per the http://wiki.apache.org/cassandra/CompatibilityGuarantees
(changing the internode protocol, for instance).
if we're willing to trade on those Guarantees, then sure, majors are just
bike shedding the version numbers, but I suspect we don't want to do that ;)
That being said, I completely understand the frustration of "one more week,
X is almost ready and we don't want to wait a year to get it in". I offer
two points, though:
1) This is an open source project, with no real business requirements to
ship any version by any specific date. We want to ship often enough to be
relevant as a project/product, of course, but there's no financial or
business requirement to do so.
2) We could have better planning as to what we actually want to ship in a
"version", or at least have some agreed upon mid- to long-term roadmap.
This would help focus the calendar and the project. Currently, it's largely
willy-nilly as to what ships when, and while tick-tock has introduced
regularity wrt release dates, there's not much that shapes what goes in
those releases.
My two cents,
-Jason
On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sy...@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 <jb...@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
> >
>
Re: Blockers for 4.0
Posted by Sylvain Lebresne <sy...@datastax.com>.
On Thu, Jul 21, 2016 at 4:38 PM, Jason Brown <ja...@gmail.com> wrote:
> Sylvain,
>
> In the large, yes, that is the best "have enough mechanism in place that no
> further ticket _have to_ wait for a major", but many of the tickets we are
> talking about makes changes to things we've all agreed can *only* happen at
> majors, as per the
> http://wiki.apache.org/cassandra/CompatibilityGuarantees
> (changing the internode protocol, for instance).
>
I don't think we ever agreed that being able to only make *any* kind of
change to
the intra-node protocol (to take that example) was a good thing. We merely
agreed that this was kind of necessary due to the problem I'm suggesting we
tackle (and some other we already tackled).
That, and the fact that until tick-tock we were supposed to add feature only
in major releases in the first place. In tick-tock, every feature release
is kind
of a major, and the fact we have to wait on some "super"-major for some
issue
is wrong.
>
> if we're willing to trade on those Guarantees, then sure, majors are just
> bike shedding the version numbers, but I suspect we don't want to do that
> ;)
>
That's exactly what I'm suggesting, and I'd be somewhat surprised we don't
want to because I'm convinced it's the right thing to do :)
>
> That being said, I completely understand the frustration of "one more week,
> X is almost ready and we don't want to wait a year to get it in". I offer
> two points, though:
> 1) This is an open source project, with no real business requirements to
> ship any version by any specific date. We want to ship often enough to be
> relevant as a project/product, of course, but there's no financial or
> business requirement to do so.
> 2) We could have better planning as to what we actually want to ship in a
> "version", or at least have some agreed upon mid- to long-term roadmap.
> This would help focus the calendar and the project. Currently, it's largely
> willy-nilly as to what ships when, and while tick-tock has introduced
> regularity wrt release dates, there's not much that shapes what goes in
> those releases.
>
> My two cents,
>
> -Jason
>
>
>
> On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sy...@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 <jb...@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
> > >
> >
>
Re: Blockers for 4.0
Posted by Jason Brown <ja...@gmail.com>.
Sylvain,
In the large, yes, that is the best "have enough mechanism in place that no
further ticket _have to_ wait for a major", but many of the tickets we are
talking about makes changes to things we've all agreed can *only* happen at
majors, as per the http://wiki.apache.org/cassandra/CompatibilityGuarantees
(changing the internode protocol, for instance).
if we're willing to trade on those Guarantees, then sure, majors are just
bike shedding the version numbers, but I suspect we don't want to do that ;)
That being said, I completely understand the frustration of "one more week,
X is almost ready and we don't want to wait a year to get it in". I offer
two points, though:
1) This is an open source project, with no real business requirements to
ship any version by any specific date. We want to ship often enough to be
relevant as a project/product, of course, but there's no financial or
business requirement to do so.
2) We could have better planning as to what we actually want to ship in a
"version", or at least have some agreed upon mid- to long-term roadmap.
This would help focus the calendar and the project. Currently, it's largely
willy-nilly as to what ships when, and while tick-tock has introduced
regularity wrt release dates, there's not much that shapes what goes in
those releases.
My two cents,
-Jason
On Thu, Jul 21, 2016 at 7:02 AM, Sylvain Lebresne <sy...@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 <jb...@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
> >
>
Re: Blockers for 4.0
Posted by Sylvain Lebresne <sy...@datastax.com>.
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 <jb...@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
>