You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Oleksandr Petrov <ol...@gmail.com> on 2017/11/07 14:41:56 UTC
V5 as a protocol beta version in 3.11
Hi everyone,
Currently, 3.11 supports V5 as a protocol version. However, all new
features are now going to 4.0, which is going to be a new feature release.
Right now we have two v5 features:
- CASSANDRA-10786 <https://issues.apache.org/jira/browse/CASSANDRA-10786>
- CASSANDRA-12838 <https://issues.apache.org/jira/browse/CASSANDRA-12838>
#12838 is adding duration type, which is a nice addition. #10786 is also
useful, but is more of an edge cases for users with huge clusters and/or
frequent schema changes.
If we leave v5 in 3.11, we'll have to always backport all v5 features to
3.11. This is something that hasn't been done in #10786. So the question
is: are we ready to commit and support v5 in 3.11 "forever", or should we
stop until it went too far and remove v5 from 3.11 since it's still in beta
there.
Looking forward to hear your opinion,
--
Alex Petrov
Re: V5 as a protocol beta version in 3.11
Posted by Alex P <ol...@gmail.com>.
This makes sense and is alongside with the previous discussions about v5. I agree with Adam and Jeremiah on that.
Thank you for the input. I will adjust the tests tomorrow.
Best regards,
Alex Petrov
> On 7. Nov 2017, at 18:32, Adam Holmberg <ad...@datastax.com> wrote:
>
> I agree that it is okay to leave v5 beta behind. As I recall, the point of
> beta was less about trying stuff early, but more to allow early
> implementation and testing of new protocol features, before the scope was
> finalized. Now that v5 proper has diverged from beta it is no longer
> supported. I don't see much value in back-porting, nor do I think we
> should increment versions in order to maintain compatibility with
> something that was expressly beta.
>
> I think we should disable v5 testing in 3.x branch and let the v5 spec
> continue to evolve in *non-beta* status in 4.0 until it is finalized upon
> release.
>
> Adam Holmberg
>
> On Tue, Nov 7, 2017 at 10:57 AM, J. D. Jordan <je...@gmail.com>
> wrote:
>
>> Again. V5 beta in 3.11 was always meant to stop working when future things
>> happened to V5 in the drivers and in C*. I see no problem with leaving the
>> beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have
>> the full non beta V5 with extra stuff in it, and will not work with beta V5.
>> Nothing uses the beta V5 by default. It is an opt in thing to be used if
>> you wanted to try out stuff early.
>>
>> -Jeremiah
>>
>>> On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <
>> oleksandr.petrov@gmail.com> wrote:
>>>
>>> This is an option, you're right. In this case v5 will have just one
>>> feature, however, and the only feature (Duration type) should work with
>> via
>>> CustomTypes through v4.
>>>
>>> Looks like the Jira numbers were off, so let me do it again:
>>>
>>> In 3.11 we have:
>>> * CASSANDRA-12838 - Extend native protocol flags and add supported
>>> versions to the SUPPORTED response
>>> * CASSANDRA-12142 - Add "beta" version native protocol flag
>>> * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
>>> one should also work with v4)
>>>
>>> In 4.0 we have
>>> * CASSANDRA-10786 - Include hash of result set metadata in prepared
>>> statement id
>>>
>>> And the options:
>>>
>>> * (1) remove v5 from 3.11 by reverting #12838 and #12142
>>> * (2) support v5 in 3.11 forever and backport #10786
>>> * (3) bump 4.0 version to v6 and make sure that #10786 is v6
>>>
>>> Question with (1) is mostly whether or not we would like to cut another
>>> version release because of (in essence) #12838 only, since #12142 is not
>>> relevant in the context and #12850 will still work.
>>>
>>>
>>>
>>>> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad <jo...@jonhaddad.com>
>> wrote:
>>>>
>>>> The other option, to avoid having two different v5 implementations, is
>> to
>>>> bump 4.0’s protocol version to 6.
>>>> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
>>>> jeremiah.jordan@gmail.com>
>>>> wrote:
>>>>
>>>>> My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
>>>>> for tick/tock stuff and known that when a new version came out it would
>>>>> most possibly break the older releases V5 beta stuff? Or at the very
>>>> least
>>>>> add new things to V5. So I see no reason to need to add more new
>>>> features
>>>>> to 3.11 v5.
>>>>>
>>>>> -Jeremiah
>>>>>
>>>>>> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
>>>> oleksandr.petrov@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> Currently, 3.11 supports V5 as a protocol version. However, all new
>>>>>> features are now going to 4.0, which is going to be a new feature
>>>>> release.
>>>>>>
>>>>>> Right now we have two v5 features:
>>>>>>
>>>>>> - CASSANDRA-10786 <
>>>>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
>>>>>> - CASSANDRA-12838 <
>>>>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
>>>>>>
>>>>>>
>>>>>> #12838 is adding duration type, which is a nice addition. #10786 is
>>>> also
>>>>>> useful, but is more of an edge cases for users with huge clusters
>>>> and/or
>>>>>> frequent schema changes.
>>>>>>
>>>>>> If we leave v5 in 3.11, we'll have to always backport all v5 features
>>>> to
>>>>>> 3.11. This is something that hasn't been done in #10786. So the
>>>> question
>>>>>> is: are we ready to commit and support v5 in 3.11 "forever", or should
>>>> we
>>>>>> stop until it went too far and remove v5 from 3.11 since it's still in
>>>>> beta
>>>>>> there.
>>>>>>
>>>>>> Looking forward to hear your opinion,
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alex Petrov
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>>>
>>>>>
>>>>
>>> --
>>> Alex Petrov
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: V5 as a protocol beta version in 3.11
Posted by Adam Holmberg <ad...@datastax.com>.
I agree that it is okay to leave v5 beta behind. As I recall, the point of
beta was less about trying stuff early, but more to allow early
implementation and testing of new protocol features, before the scope was
finalized. Now that v5 proper has diverged from beta it is no longer
supported. I don't see much value in back-porting, nor do I think we
should increment versions in order to maintain compatibility with
something that was expressly beta.
I think we should disable v5 testing in 3.x branch and let the v5 spec
continue to evolve in *non-beta* status in 4.0 until it is finalized upon
release.
Adam Holmberg
On Tue, Nov 7, 2017 at 10:57 AM, J. D. Jordan <je...@gmail.com>
wrote:
> Again. V5 beta in 3.11 was always meant to stop working when future things
> happened to V5 in the drivers and in C*. I see no problem with leaving the
> beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have
> the full non beta V5 with extra stuff in it, and will not work with beta V5.
> Nothing uses the beta V5 by default. It is an opt in thing to be used if
> you wanted to try out stuff early.
>
> -Jeremiah
>
> > On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <
> oleksandr.petrov@gmail.com> wrote:
> >
> > This is an option, you're right. In this case v5 will have just one
> > feature, however, and the only feature (Duration type) should work with
> via
> > CustomTypes through v4.
> >
> > Looks like the Jira numbers were off, so let me do it again:
> >
> > In 3.11 we have:
> > * CASSANDRA-12838 - Extend native protocol flags and add supported
> > versions to the SUPPORTED response
> > * CASSANDRA-12142 - Add "beta" version native protocol flag
> > * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
> > one should also work with v4)
> >
> > In 4.0 we have
> > * CASSANDRA-10786 - Include hash of result set metadata in prepared
> > statement id
> >
> > And the options:
> >
> > * (1) remove v5 from 3.11 by reverting #12838 and #12142
> > * (2) support v5 in 3.11 forever and backport #10786
> > * (3) bump 4.0 version to v6 and make sure that #10786 is v6
> >
> > Question with (1) is mostly whether or not we would like to cut another
> > version release because of (in essence) #12838 only, since #12142 is not
> > relevant in the context and #12850 will still work.
> >
> >
> >
> >> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad <jo...@jonhaddad.com>
> wrote:
> >>
> >> The other option, to avoid having two different v5 implementations, is
> to
> >> bump 4.0’s protocol version to 6.
> >> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
> >> jeremiah.jordan@gmail.com>
> >> wrote:
> >>
> >>> My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
> >>> for tick/tock stuff and known that when a new version came out it would
> >>> most possibly break the older releases V5 beta stuff? Or at the very
> >> least
> >>> add new things to V5. So I see no reason to need to add more new
> >> features
> >>> to 3.11 v5.
> >>>
> >>> -Jeremiah
> >>>
> >>>> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
> >> oleksandr.petrov@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hi everyone,
> >>>>
> >>>> Currently, 3.11 supports V5 as a protocol version. However, all new
> >>>> features are now going to 4.0, which is going to be a new feature
> >>> release.
> >>>>
> >>>> Right now we have two v5 features:
> >>>>
> >>>> - CASSANDRA-10786 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
> >>>> - CASSANDRA-12838 <
> >>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
> >>>>
> >>>>
> >>>> #12838 is adding duration type, which is a nice addition. #10786 is
> >> also
> >>>> useful, but is more of an edge cases for users with huge clusters
> >> and/or
> >>>> frequent schema changes.
> >>>>
> >>>> If we leave v5 in 3.11, we'll have to always backport all v5 features
> >> to
> >>>> 3.11. This is something that hasn't been done in #10786. So the
> >> question
> >>>> is: are we ready to commit and support v5 in 3.11 "forever", or should
> >> we
> >>>> stop until it went too far and remove v5 from 3.11 since it's still in
> >>> beta
> >>>> there.
> >>>>
> >>>> Looking forward to hear your opinion,
> >>>>
> >>>>
> >>>> --
> >>>> Alex Petrov
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> >>> For additional commands, e-mail: dev-help@cassandra.apache.org
> >>>
> >>>
> >>
> > --
> > Alex Petrov
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: V5 as a protocol beta version in 3.11
Posted by "J. D. Jordan" <je...@gmail.com>.
Again. V5 beta in 3.11 was always meant to stop working when future things happened to V5 in the drivers and in C*. I see no problem with leaving the beta V5, which is an opt in thing to try out, in 3.11 alone. 4.0 will have the full non beta V5 with extra stuff in it, and will not work with beta V5.
Nothing uses the beta V5 by default. It is an opt in thing to be used if you wanted to try out stuff early.
-Jeremiah
> On Nov 7, 2017, at 11:39 AM, Oleksandr Petrov <ol...@gmail.com> wrote:
>
> This is an option, you're right. In this case v5 will have just one
> feature, however, and the only feature (Duration type) should work with via
> CustomTypes through v4.
>
> Looks like the Jira numbers were off, so let me do it again:
>
> In 3.11 we have:
> * CASSANDRA-12838 - Extend native protocol flags and add supported
> versions to the SUPPORTED response
> * CASSANDRA-12142 - Add "beta" version native protocol flag
> * CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
> one should also work with v4)
>
> In 4.0 we have
> * CASSANDRA-10786 - Include hash of result set metadata in prepared
> statement id
>
> And the options:
>
> * (1) remove v5 from 3.11 by reverting #12838 and #12142
> * (2) support v5 in 3.11 forever and backport #10786
> * (3) bump 4.0 version to v6 and make sure that #10786 is v6
>
> Question with (1) is mostly whether or not we would like to cut another
> version release because of (in essence) #12838 only, since #12142 is not
> relevant in the context and #12850 will still work.
>
>
>
>> On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad <jo...@jonhaddad.com> wrote:
>>
>> The other option, to avoid having two different v5 implementations, is to
>> bump 4.0’s protocol version to 6.
>> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
>> jeremiah.jordan@gmail.com>
>> wrote:
>>
>>> My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
>>> for tick/tock stuff and known that when a new version came out it would
>>> most possibly break the older releases V5 beta stuff? Or at the very
>> least
>>> add new things to V5. So I see no reason to need to add more new
>> features
>>> to 3.11 v5.
>>>
>>> -Jeremiah
>>>
>>>> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
>> oleksandr.petrov@gmail.com>
>>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Currently, 3.11 supports V5 as a protocol version. However, all new
>>>> features are now going to 4.0, which is going to be a new feature
>>> release.
>>>>
>>>> Right now we have two v5 features:
>>>>
>>>> - CASSANDRA-10786 <
>>> https://issues.apache.org/jira/browse/CASSANDRA-10786>
>>>> - CASSANDRA-12838 <
>>> https://issues.apache.org/jira/browse/CASSANDRA-12838>
>>>>
>>>>
>>>> #12838 is adding duration type, which is a nice addition. #10786 is
>> also
>>>> useful, but is more of an edge cases for users with huge clusters
>> and/or
>>>> frequent schema changes.
>>>>
>>>> If we leave v5 in 3.11, we'll have to always backport all v5 features
>> to
>>>> 3.11. This is something that hasn't been done in #10786. So the
>> question
>>>> is: are we ready to commit and support v5 in 3.11 "forever", or should
>> we
>>>> stop until it went too far and remove v5 from 3.11 since it's still in
>>> beta
>>>> there.
>>>>
>>>> Looking forward to hear your opinion,
>>>>
>>>>
>>>> --
>>>> Alex Petrov
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>>
>>
> --
> Alex Petrov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org
Re: V5 as a protocol beta version in 3.11
Posted by Oleksandr Petrov <ol...@gmail.com>.
This is an option, you're right. In this case v5 will have just one
feature, however, and the only feature (Duration type) should work with via
CustomTypes through v4.
Looks like the Jira numbers were off, so let me do it again:
In 3.11 we have:
* CASSANDRA-12838 - Extend native protocol flags and add supported
versions to the SUPPORTED response
* CASSANDRA-12142 - Add "beta" version native protocol flag
* CASSANDRA-12850 - Add the duration type to the protocol V5 <-- (this
one should also work with v4)
In 4.0 we have
* CASSANDRA-10786 - Include hash of result set metadata in prepared
statement id
And the options:
* (1) remove v5 from 3.11 by reverting #12838 and #12142
* (2) support v5 in 3.11 forever and backport #10786
* (3) bump 4.0 version to v6 and make sure that #10786 is v6
Question with (1) is mostly whether or not we would like to cut another
version release because of (in essence) #12838 only, since #12142 is not
relevant in the context and #12850 will still work.
On Tue, Nov 7, 2017 at 4:19 PM Jonathan Haddad <jo...@jonhaddad.com> wrote:
> The other option, to avoid having two different v5 implementations, is to
> bump 4.0’s protocol version to 6.
> On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <
> jeremiah.jordan@gmail.com>
> wrote:
>
> > My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
> > for tick/tock stuff and known that when a new version came out it would
> > most possibly break the older releases V5 beta stuff? Or at the very
> least
> > add new things to V5. So I see no reason to need to add more new
> features
> > to 3.11 v5.
> >
> > -Jeremiah
> >
> > > On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <
> oleksandr.petrov@gmail.com>
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > Currently, 3.11 supports V5 as a protocol version. However, all new
> > > features are now going to 4.0, which is going to be a new feature
> > release.
> > >
> > > Right now we have two v5 features:
> > >
> > > - CASSANDRA-10786 <
> > https://issues.apache.org/jira/browse/CASSANDRA-10786>
> > > - CASSANDRA-12838 <
> > https://issues.apache.org/jira/browse/CASSANDRA-12838>
> > >
> > >
> > > #12838 is adding duration type, which is a nice addition. #10786 is
> also
> > > useful, but is more of an edge cases for users with huge clusters
> and/or
> > > frequent schema changes.
> > >
> > > If we leave v5 in 3.11, we'll have to always backport all v5 features
> to
> > > 3.11. This is something that hasn't been done in #10786. So the
> question
> > > is: are we ready to commit and support v5 in 3.11 "forever", or should
> we
> > > stop until it went too far and remove v5 from 3.11 since it's still in
> > beta
> > > there.
> > >
> > > Looking forward to hear your opinion,
> > >
> > >
> > > --
> > > Alex Petrov
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> > For additional commands, e-mail: dev-help@cassandra.apache.org
> >
> >
>
--
Alex Petrov
Re: V5 as a protocol beta version in 3.11
Posted by Jonathan Haddad <jo...@jonhaddad.com>.
The other option, to avoid having two different v5 implementations, is to
bump 4.0’s protocol version to 6.
On Tue, Nov 7, 2017 at 6:48 AM Jeremiah D Jordan <je...@gmail.com>
wrote:
> My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol
> for tick/tock stuff and known that when a new version came out it would
> most possibly break the older releases V5 beta stuff? Or at the very least
> add new things to V5. So I see no reason to need to add more new features
> to 3.11 v5.
>
> -Jeremiah
>
> > On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <ol...@gmail.com>
> wrote:
> >
> > Hi everyone,
> >
> > Currently, 3.11 supports V5 as a protocol version. However, all new
> > features are now going to 4.0, which is going to be a new feature
> release.
> >
> > Right now we have two v5 features:
> >
> > - CASSANDRA-10786 <
> https://issues.apache.org/jira/browse/CASSANDRA-10786>
> > - CASSANDRA-12838 <
> https://issues.apache.org/jira/browse/CASSANDRA-12838>
> >
> >
> > #12838 is adding duration type, which is a nice addition. #10786 is also
> > useful, but is more of an edge cases for users with huge clusters and/or
> > frequent schema changes.
> >
> > If we leave v5 in 3.11, we'll have to always backport all v5 features to
> > 3.11. This is something that hasn't been done in #10786. So the question
> > is: are we ready to commit and support v5 in 3.11 "forever", or should we
> > stop until it went too far and remove v5 from 3.11 since it's still in
> beta
> > there.
> >
> > Looking forward to hear your opinion,
> >
> >
> > --
> > Alex Petrov
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>
>
Re: V5 as a protocol beta version in 3.11
Posted by Jeremiah D Jordan <je...@gmail.com>.
My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol for tick/tock stuff and known that when a new version came out it would most possibly break the older releases V5 beta stuff? Or at the very least add new things to V5. So I see no reason to need to add more new features to 3.11 v5.
-Jeremiah
> On Nov 7, 2017, at 9:41 AM, Oleksandr Petrov <ol...@gmail.com> wrote:
>
> Hi everyone,
>
> Currently, 3.11 supports V5 as a protocol version. However, all new
> features are now going to 4.0, which is going to be a new feature release.
>
> Right now we have two v5 features:
>
> - CASSANDRA-10786 <https://issues.apache.org/jira/browse/CASSANDRA-10786>
> - CASSANDRA-12838 <https://issues.apache.org/jira/browse/CASSANDRA-12838>
>
>
> #12838 is adding duration type, which is a nice addition. #10786 is also
> useful, but is more of an edge cases for users with huge clusters and/or
> frequent schema changes.
>
> If we leave v5 in 3.11, we'll have to always backport all v5 features to
> 3.11. This is something that hasn't been done in #10786. So the question
> is: are we ready to commit and support v5 in 3.11 "forever", or should we
> stop until it went too far and remove v5 from 3.11 since it's still in beta
> there.
>
> Looking forward to hear your opinion,
>
>
> --
> Alex Petrov
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org