Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Jonathan Ellis]

Added those to the list, thanks.

On Tue, May 12, 2015 at 3:30 AM, Robert Stupp  wrote:

> 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 :
> >
> > 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 
> 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 
> >> 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  >
> >>> 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
>
>


-- 
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)

[Robert Stupp]

I’ve got one - UDF using ecj instead of javassist 
(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 
).

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 :
> 
> 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  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 
>> 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 
>>> 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)

[Marcus Eriksson]

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  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 
> 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 
> > 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)

[Michael Kjellman]

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  wrote:
> 
> On Mon, May 11, 2015 at 2:16 PM, Jonathan Haddad  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  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 
>> wrote:
>>> 
 On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Alex Popescu]

On Mon, May 11, 2015 at 2:16 PM, Jonathan Haddad  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  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 
> wrote:
> >
> > > On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Alex Popescu]

Another option could be 2.1 -> 2.5* -> 3.0

This would still emphasize the major new features and changes in both
versions.

(*) unfortunately 2.5 would not help for drivers, so labeling 2.6 would get
my +1.

On Mon, May 11, 2015 at 2:09 PM, Jonathan Ellis  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  wrote:
>
> > On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Jonathan Haddad]

I'm not sure if the complications surrounding the versioning of the drivers
should be factored into the releases of Cassandra.  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.


On Mon, May 11, 2015 at 2:09 PM Jonathan Ellis  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  wrote:
>
> > On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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)

[Jonathan Ellis]

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  wrote:

> On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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)

[Alex Popescu]

On Mon, May 11, 2015 at 1:41 PM, Aleksey Yeschenko 
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)

[Aleksey Yeschenko]

Can you not alter the version of the drivers, though? 3.0 to 2.2?

-- 
AY

On May 11, 2015 at 23:38:00, Alex Popescu (al...@datastax.com) wrote:

On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko   
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)

[Jake Luciani]

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  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)

[Alex Popescu]

On Mon, May 11, 2015 at 1:32 PM, Aleksey Yeschenko 
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)

[Brian Hess]

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 
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  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 
> > 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 
> >> 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)

[Aleksey Yeschenko]

The drivers, actually, aren’t ready at all for 3.0 with 8099, because 6717 will 
be pushed shortly after 8099, and break things.

-- 
AY

On May 11, 2015 at 23:29:13, Alex Popescu (al...@datastax.com) wrote:

On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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)

[Alex Popescu]

On Sun, May 10, 2015 at 2:14 PM, Robert Stupp  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)

[Jeremiah Jordan]

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  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 
> 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 
>> 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)

[Jonathan Ellis]

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  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 
> 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 
>> 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)

[Brian Hess]

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 
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 
> 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)

[Jonathan Ellis]

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 
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 
> 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)

[Aleksey Yeschenko]

> 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   
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)

[Jonathan Ellis]

On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko 
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)

[Robert Stupp]

+1 on the idea of releasing what’s already there and what’s possible without 
big effort for 3.0.

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.

> Am 10.05.2015 um 21:42 schrieb Aleksey Yeschenko :
> 
> Releasing a 2.2 now is indeed a good idea, +1 to that.
> 
> Regarding EOLs, however, there I don’t feel like dropping the planned 3.0.x 
> stabilisation branch is necessary.
> 
> I’d also say that having both 2.1.x and 2.2.x LTS branches is both 1) very 
> cheap for us and 2) is not really needed.
> 
> Here is why:
> 
> 1) The new features in 2.2 don’t modify the core heavily - unlike 3.0 would. 
> Hence 2.1 patches almost always apply cleanly to trunk, not causing us 
> headaches as developers
> 
> 2) New features being almost entirely opt-in, if you don’t use them, you can 
> jump from 2.1 to 2.2 without significant stability degradation. It’s only the 
> new features, in this case, that require stabilising. Messaging formats 
> haven’t changed, sstable format is the same, the storage engine has had no 
> modifications.
> 
> So, maintaining both 2.1 and 2.2 LTS branches, while cheap for us, is 
> unnecessary, and would cause avoidable fragmentation.
> 
> 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.
> 
> So I’d suggest a third EOL alternative. We leave the planned 3.0.x 
> stabilisation branch in place - we are going to need it. And we have the new 
> 2.2 branch inherit 2.1’s LTS status, and retire 2.1 itself earlier than 
> planned. In other words,
> 
> 1) 2.0.x branch goes EOL when 3.0 is out, as planned
> 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage 
> engine
> 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
> 
> With that addition, +100 to the idea of having a 2.2 ASAP.
> 
> -- 
> AY
> 
> On May 10, 2015 at 17:28:05, Phil Yang (ud1...@gmail.com) wrote:
> 
> How about naming it 2.9 as a development preview version before 3.0? If  
> this version and 3.0 are close in functionality, it is not a good idea that  
> the two version number have a huge difference. And after 3.0 being shipped,  
> I think we should stop maintaining this version because of the similarity  
> with 3.0 and still maintain 2.1.x since 2.1.0 was shipped 8 months ago and  
> just have a "maybe product ready" version 2.1.5.  
> 
> 
> 2015-05-10 20:17 GMT+08:00 :  
> 
>> To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to  
>> 8099, in order to not block certain key features, as mentioned. Neutral  
>> on any additional nuances.  
>> 
>> -Tupshin  
>> 
>> On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote:  
>>> +1  
>>> 
>>> On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis 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  
 Pr

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Aleksey Yeschenko]

Releasing a 2.2 now is indeed a good idea, +1 to that.

Regarding EOLs, however, there I don’t feel like dropping the planned 3.0.x 
stabilisation branch is necessary.

I’d also say that having both 2.1.x and 2.2.x LTS branches is both 1) very 
cheap for us and 2) is not really needed.

Here is why:

1) The new features in 2.2 don’t modify the core heavily - unlike 3.0 would. 
Hence 2.1 patches almost always apply cleanly to trunk, not causing us 
headaches as developers

2) New features being almost entirely opt-in, if you don’t use them, you can 
jump from 2.1 to 2.2 without significant stability degradation. It’s only the 
new features, in this case, that require stabilising. Messaging formats haven’t 
changed, sstable format is the same, the storage engine has had no 
modifications.

So, maintaining both 2.1 and 2.2 LTS branches, while cheap for us, is 
unnecessary, and would cause avoidable fragmentation.

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.

So I’d suggest a third EOL alternative. We leave the planned 3.0.x 
stabilisation branch in place - we are going to need it. And we have the new 
2.2 branch inherit 2.1’s LTS status, and retire 2.1 itself earlier than 
planned. In other words,

1) 2.0.x branch goes EOL when 3.0 is out, as planned
2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new storage 
engine
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

With that addition, +100 to the idea of having a 2.2 ASAP.

-- 
AY

On May 10, 2015 at 17:28:05, Phil Yang (ud1...@gmail.com) wrote:

How about naming it 2.9 as a development preview version before 3.0? If  
this version and 3.0 are close in functionality, it is not a good idea that  
the two version number have a huge difference. And after 3.0 being shipped,  
I think we should stop maintaining this version because of the similarity  
with 3.0 and still maintain 2.1.x since 2.1.0 was shipped 8 months ago and  
just have a "maybe product ready" version 2.1.5.  


2015-05-10 20:17 GMT+08:00 :  

> To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to  
> 8099, in order to not block certain key features, as mentioned. Neutral  
> on any additional nuances.  
>  
> -Tupshin  
>  
> On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote:  
> > +1  
> >  
> > On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis 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  
>  



--  
Thanks,  
Phil Yang  

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Phil Yang]

How about naming it 2.9 as a development preview version before 3.0? If
this version and 3.0 are close in functionality, it is not a good idea that
the two version number have a huge difference. And after 3.0 being shipped,
I think we should stop maintaining this version because of the similarity
with 3.0 and still maintain 2.1.x since 2.1.0 was shipped 8 months ago and
just have a "maybe product ready" version 2.1.5.


2015-05-10 20:17 GMT+08:00 :

> To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to
> 8099, in order to not block certain key features, as mentioned. Neutral
> on any additional nuances.
>
> -Tupshin
>
> On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote:
> > +1
> >
> > On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis 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
>



-- 
Thanks,
Phil Yang

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[tupshin]

To clarify, I'm +1ing the creation of a stable 2.2 branch, prior to
8099, in order to not block certain key features, as mentioned. Neutral
on any additional nuances.

-Tupshin

On Sun, May 10, 2015, at 08:05 AM, tups...@tupshin.com wrote:
> +1
> 
> On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis 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

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[tupshin]

+1

On Sat, May 9, 2015, at 06:38 PM, Jonathan Ellis 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

Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Jonathan Ellis]

*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