cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Stupp <sn...@snazy.de>
Subject Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)
Date Tue, 12 May 2015 08:30:15 GMT
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 <krummas@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 <jbellis@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 <aleksey@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 (jbellis@gmail.com) wrote:
>>> 
>>> On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko <aleksey@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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message