Add beta version native protocol flag and ensure we have test coverage of v5




Joao Reis
April 6, 2020, 10:38 AM

I agree that it's not likely that a normal user will want to enable this but I'm worried that if it indeed happens and there is someone on the community that wants to do some testing with C* 4.0 alpha/beta, then the driver would be an obstacle and would prevent adoption instead of driving it. Best case scenario the user just switches to Java or Python but worst case scenario the user just gives up and doesn't touch C* 4.0 alpha/beta at all.

Jorge Bay Gondra
April 6, 2020, 9:07 AM

I think beta protocol versions are only useful for C* / driver devs, so I think we should avoid exposing new public API surface for supporting beta protocols, at least for now.

C* 4.0 will have v5 as non-beta, so it’s only useful to send that flag as part of the C* 4.0 testing.

Joao Reis
April 2, 2020, 4:30 PM

My proposal is to add a Builder.WithBetaProtocolVersions() method with no parameters to make the protocol version negotiation mechanism consider beta protocol versions.

Additionally, we could also consider adding an overload in the future like Builder.WithBetaProtocolVersions(IEnumerable<ProtocolVersion> versions) to allow the user to whitelist specific beta protocol versions but I don't think it will be necessary. If we want to add a way to whitelist/blacklist protocol versions in the future, it would make more sense to do it for all versions (not only beta versions) imo.

Alex Dutra
March 25, 2020, 5:17 PM

It’s good to add the beta flag, but as far as protocol v5 is concerned, let’s keep in mind that it is actually transitioning out of beta status, see CASSANDRA-14973. So in this ticket, we might want to focus on 1) creating the flag and 2) making sure v5 is fully usable as a non-beta protocol.





Joao Reis


Fix versions

Epic Link