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 <jeremiah.jor...@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.pet...@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 <j...@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.jor...@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.pet...@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-unsubscr...@cassandra.apache.org > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org > >>> > >>> > >> > > -- > > Alex Petrov > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
