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
