After a little bit of investigation, it turns out that we can't bring v5 out of
beta in 3.11 as there are already a number of v5 features which 3.11 doesn't
support. This necessarily couples the C*, protocol and driver versions. For
instance, java driver 3.0.x is able to support v5 with 3.11, but not with 4.0
(and the inverse is true of driver 3.10.x). Going back to the genesis of v5 in
CASSANDRA-10786, this was always the intent:
"v5 beta" will mean different things at different times, and there might be
errors when an older driver version (supporting "v5 beta with new feature A")
connects to a newer C* version (supporting "v5 beta with new features A and
B"). But with the provision that "bad things can happen when you're in beta"
that's acceptable, so we don't need to make things any more complicated." [1]
This simplifies things, we promote v5 out of beta in trunk only with no need to
bump the framing format to v6-beta. If clients currently using v5-beta on
3.11.x want to upgrade their drivers, they must either revert to v4 or upgrade
the cluster to 4.0. Because CI uses the same python driver version for all C*
branches, we'll need to make dtests which require v5 exclusive to 4.0, which
I'll take care of. Tickets already exist for the python and java drivers
([2],[3],[4]), but we'll need to bundle a SNAPSHOT java driver with C*
temporarily for testing. I'll file a 4.0-rc blocker to replace it with a
release version, as we've done previously.
[1]
https://issues.apache.org/jira/browse/CASSANDRA-10786?focusedCommentId=15344506&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15344506
[2] https://datastax-oss.atlassian.net/browse/PYTHON-1232
[3] https://datastax-oss.atlassian.net/browse/JAVA-2704
[4] https://datastax-oss.atlassian.net/browse/JAVA-2705
> On 9 Dec 2020, at 11:02, Sam Tunnicliffe <s...@beobal.com> wrote:
>
>
>
>> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti
>> <sumanth.pasupuleti...@gmail.com> wrote:
>>
>> +1 to moving v5-beta changes in trunk to new protocol v6.
>>
>> Regarding 3.11 and v5, I suppose we could say, v5 could never get matured
>> beyond beta, but not sure if it would be confusing to see v6 while v5 is
>> still in beta (curious on others' thoughts as well)
>>
>> On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever <m...@apache.org> wrote:
>>
>>>> …move to v6 for the new protocol to avoid this issue
>>>
>>>
>>> +1, feels more the "grown-up thing to do".
>>>
>>>
>>>>> Perhaps we should skip v5…
>>>> We could finalise v5 as it was prior to the new framing format, then
>>> create v6-beta in trunk only with the 15299 changes.
>>>
>>>
>>> Would v5 come out of beta then in 3.11?, or would it stay as beta forever,
>>> with the focus on maturing v6 in 4.0+?
>>>
>
>
> Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11.
> That is, the v5 protocol itself would be identical in both C* versions, but
> there would be some considerations on the client side. Namely, if connecting
> to a cluster with any 3.11 nodes, clients would need to set the beta flag in
> CQL frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would
> simply ignore the flag, as it wouldn't be required for v5 connections. So the
> most straightforward path would be probably to promote v5 out of beta in the
> next 3.11 and 4.0-beta releases. Clients would just need to ensure that they
> stay on a *current* driver (i.e. one which sets that flag for v5) until after
> upgrading clusters to either the latest 3.11 or 4.0-beta releases.
>
> I have patches for C*, java and python drivers ready, so I'll file a JIRA and
> open some PRs.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
