Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
I’ve got one - UDF using ecj instead of javassist (https://issues.apache.org/jira/browse/CASSANDRA-8241 https://issues.apache.org/jira/browse/CASSANDRA-8241). Not sure whether the licensing thing is fine that way (about what ”appropriately labeled“ really means in https://www.apache.org/legal/resolved.html#category-b https://www.apache.org/legal/resolved.html#category-b). One thing that may annoy using UDFs w/ tuples UDTs is #9186. It’s about frozen“ getting lost in the signature. Probably also include #9229 (timeuuid to date/time conversion) ? Am 12.05.2015 um 09:05 schrieb Marcus Eriksson krum...@gmail.com: We should get https://issues.apache.org/jira/browse/CASSANDRA-8568 in 2.2 as well (it is patch avail and I'll get it reviewed this week) /Marcus On Mon, May 11, 2015 at 9:42 PM, Jonathan Ellis jbel...@gmail.com wrote: Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- 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 — Robert Stupp @snazy
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
We should get https://issues.apache.org/jira/browse/CASSANDRA-8568 in 2.2 as well (it is patch avail and I'll get it reviewed this week) /Marcus On Mon, May 11, 2015 at 9:42 PM, Jonathan Ellis jbel...@gmail.com wrote: Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- 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: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko alek...@apache.org wrote: The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 will be pushed shortly after 8099, and break things. Apologies, I didn't mean they are ready today. Version-wise, renaming this proposed 2.2 to 3.0 would allow us to maintain a versioning policy that made things quite simple for users: Cassandra version == driver version. -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
One thing that does jump out at me, though, is about CQL2. As much as we have advised against using cassandra-jdbc, I have encountered a few that actually have used that as an integration point. I believe that cassandra-jdbc is CQL2-based, which is the main reason we have been advising folks against it. Can we just confirm that there isn't in fact widespread use of CQL2-based cassandra-jdbc? That just jumps out at me. On Mon, May 11, 2015 at 2:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
On Mon, May 11, 2015 at 1:41 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0 to 2.2? Python and C# have already used 2.5 (I wouldn't have brought this up if I had other options). -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- 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: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never recommend it) is that it does cql3 over thrift. So you lose out on all the native protocol features. On May 11, 2015, at 2:53 PM, Brian Hess brianmh...@gmail.com wrote: One thing that does jump out at me, though, is about CQL2. As much as we have advised against using cassandra-jdbc, I have encountered a few that actually have used that as an integration point. I believe that cassandra-jdbc is CQL2-based, which is the main reason we have been advising folks against it. Can we just confirm that there isn't in fact widespread use of CQL2-based cassandra-jdbc? That just jumps out at me. On Mon, May 11, 2015 at 2:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
On Sun, May 10, 2015 at 2:14 PM, Robert Stupp sn...@snazy.de wrote: Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so basically just move 8099 to 3.1). In the end it’s ”only a label”. But there are a lot of new user-facing features in it that justifies a major release. +1 on labeling the proposed 2.2 as 3.0 and moving (8099 to 3.1) 1. Tons of new features that feel more than just a 2.2 2. The majority of features planned for 3.0 are actually ready for this version 3. in order to avoid compatiblity questions (and version compatibility matrices), the drivers developed by DataStax have followed the Cassandra versions so far. The Python and C# drivers are already at 2.5 as they added some major features. Renaming the proposed 2.2 as 3.0 would allow us to continue to use this versioning policy until all drivers are supporting the latest Cassandra version and continue to not require a user to check a compatibility matrix. -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Overall +1. I'm -0 on EOL of 2.0 once 2.2 is release. I'd rather keep 2.0 around till 3.0 comes out. As for 2.2 blockers, we might want to vet and make sure everything we need in protocol v4 is finished before we release 2.2 https://issues.apache.org/jira/browse/CASSANDRA-8043 On Sat, May 9, 2015 at 6:38 PM, Jonathan Ellis jbel...@gmail.com 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 -- http://twitter.com/tjake
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Unresolved issues tagged for 2.2b1: https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20fixVersion%20%3D%20%222.2%20beta%201%22%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC On Mon, May 11, 2015 at 2:42 PM, Jonathan Ellis jbel...@gmail.com wrote: Sounds good. I will add the new version to Jira. Planned tickets to block 2.2 beta for: #8374 #8984 #9190 Any others? (If it's not code complete today we should not block for it.) On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- 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 -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Jeremiah - still need to worry about whether folks are doing CQL2 or CQL3 over cassandra-jdbc. If it is not in much use, that's fine by me. I just wanted to raise one place where folks might be using CQL2 without realizing it. On Mon, May 11, 2015 at 4:00 PM, Jeremiah Jordan jerem...@datastax.com wrote: Cassandra-jdbc can do cql3 as well as cql2. The rub (and why I would never recommend it) is that it does cql3 over thrift. So you lose out on all the native protocol features. On May 11, 2015, at 2:53 PM, Brian Hess brianmh...@gmail.com wrote: One thing that does jump out at me, though, is about CQL2. As much as we have advised against using cassandra-jdbc, I have encountered a few that actually have used that as an integration point. I believe that cassandra-jdbc is CQL2-based, which is the main reason we have been advising folks against it. Can we just confirm that there isn't in fact widespread use of CQL2-based cassandra-jdbc? That just jumps out at me. On Mon, May 11, 2015 at 2:59 PM, Aleksey Yeschenko alek...@apache.org wrote: So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. Given how long 2.0.x has been alive now, and the stability of 2.1.x at the moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out. Can’t argue here. If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? Under our current projections, that’ll be exactly “a few months after 2.2 is released”, so I’m again fine with it. P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog So long as you don’t you compressed CL, you should be solid. You are probably solid even if you do use compressed CL. Here are my only concerns: 1. New authz are not opt-in. If a user implements their own custom authenticator or authorized, they’d have to upgrade them sooner. The test coverage for new authnz, however, is better than the coverage we used to have before. 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In practice, however, I highly doubt that anybody using CQL2 is also someone who’d already switch to 2.1.x or 2.2.x. -- AY On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote: On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko alek...@apache.org wrote: 3.0, however, will require a stabilisation period, just by the nature of it. It might seem like 2.2 and 3.0 are closer to each other than 2.1 and 2.2 are, if you go purely by the feature list, but in fact the opposite is true. You are probably right. But let me push back on some of the extra work you're proposing just a little: 1) 2.0.x branch goes EOL when 3.0 is out, as planned 3.0 was, however unrealistically, planned for April. And it's moving the goalposts to say the plan was always to keep 2.0.x for three major releases; the plan was to EOL with the next major release after 2.1 whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2 comes out is reasonable, especially considering that 2.2 is realistically a month or two away even if we can get a beta out this week. 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage engine Yes. 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade to 2.2, get the same stability as with 2.1.7, plus a few new features If push comes to shove I'm okay being ambiguous here, but can we just say when 3.0 is released we EOL 2.1? P.S. The area I'm most concerned about introducing destabilizing changes in 2.2 is commitlog; I will follow up to make sure we have a solid QA plan there. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
I do like 2.2 and 3.0 over 3.0 and 3.1 because going from 2.x to 3.x signals that 8099 really is a big change. On Mon, May 11, 2015 at 3:28 PM, Alex Popescu al...@datastax.com wrote: On Sun, May 10, 2015 at 2:14 PM, Robert Stupp sn...@snazy.de wrote: Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so basically just move 8099 to 3.1). In the end it’s ”only a label”. But there are a lot of new user-facing features in it that justifies a major release. +1 on labeling the proposed 2.2 as 3.0 and moving (8099 to 3.1) 1. Tons of new features that feel more than just a 2.2 2. The majority of features planned for 3.0 are actually ready for this version 3. in order to avoid compatiblity questions (and version compatibility matrices), the drivers developed by DataStax have followed the Cassandra versions so far. The Python and C# drivers are already at 2.5 as they added some major features. Renaming the proposed 2.2 as 3.0 would allow us to continue to use this versioning policy until all drivers are supporting the latest Cassandra version and continue to not require a user to check a compatibility matrix. -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced
Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Last I checked — and I could be wrong — we’ve never had to think about what to number a Cassandra version due to a ticket that could “impact” our users so dramatically due to the scope of the changes from a single ticket. Food for thought. love, kjellman On May 11, 2015, at 2:20 PM, Alex Popescu al...@datastax.com wrote: On Mon, May 11, 2015 at 2:16 PM, Jonathan Haddad j...@jonhaddad.com wrote: I'm not sure if the complications surrounding the versioning of the drivers should be factored into the releases of Cassandra. I agree. If we could come up with a versioning scheme that would also work for drivers, that would be the ideal case as it will prove quite helpful to our users. I think that 3.0 signals a massive change and calling the release containing 8099 a .1 would be drastically underplaying how big of a release it is - from the perspective of the end user it would be a disservice. I see. My last suggestion could work though as it signals both releases having significant impact. On Mon, May 11, 2015 at 2:09 PM Jonathan Ellis jbel...@gmail.com wrote: I do like 2.2 and 3.0 over 3.0 and 3.1 because going from 2.x to 3.x signals that 8099 really is a big change. On Mon, May 11, 2015 at 3:28 PM, Alex Popescu al...@datastax.com wrote: On Sun, May 10, 2015 at 2:14 PM, Robert Stupp sn...@snazy.de wrote: Instead of labeling it 2.2, I’d like to propose to label it 3.0 (so basically just move 8099 to 3.1). In the end it’s ”only a label”. But there are a lot of new user-facing features in it that justifies a major release. +1 on labeling the proposed 2.2 as 3.0 and moving (8099 to 3.1) 1. Tons of new features that feel more than just a 2.2 2. The majority of features planned for 3.0 are actually ready for this version 3. in order to avoid compatiblity questions (and version compatibility matrices), the drivers developed by DataStax have followed the Cassandra versions so far. The Python and C# drivers are already at 2.5 as they added some major features. Renaming the proposed 2.2 as 3.0 would allow us to continue to use this versioning policy until all drivers are supporting the latest Cassandra version and continue to not require a user to check a compatibility matrix. -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax -- Jonathan Ellis Project Chair, Apache Cassandra co-founder, http://www.datastax.com @spyced -- Bests, Alex Popescu | @al3xandru Sen. Product Manager @ DataStax
