I wanted to point out that beta version of the protocol was created [1] only for development purposes:
> This is primarily useful for driver authors to start work against a new protocol version when the work on that spans multiple releases. Users would not generally be expected to utilize this flag, although it could potentially be used to offer early feedback on new protocol features. Even at the time of creating [1], it was expected that development of the new protocol version would span multiple versions. Unless release of the new protocol version strictly coincides with a major version bump, even a major one. To use a beta flag, one absolutely has to have matching server and client versions, since otherwise things can break in unexpected ways. In fact, this specific issue makes it easy since you'd see that something has changed immediately. +1 to have 4.0 with v5. [1] https://issues.apache.org/jira/browse/CASSANDRA-12142 On Fri, Dec 11, 2020 at 5:02 PM Sam Tunnicliffe <s...@beobal.com> wrote: > > 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 > > -- alex p
