> 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
