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 >
