> Nit-picking, "beta" isn't sounding like the most accurate classifier
here. It sounds to me more like it is "in development", i.e. 'dev', rather
than beta.
I agree that `dev` rather than `beta` is a better classifier. We probably
should rename it at least internally and in the spec. That might b
> What's the verdict now for CASSANDRA-14973 ?
My aim is to have a C* patch and PRs for the python and java drivers this week,
but really there's nothing to block cutting a new C* beta now (or whenever
we're ready).
> On 15 Dec 2020, at 15:39, Mick Semb Wever wrote:
>
>>
>> To use a beta fla
>
> 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.
>
That could certainly deserve better documentation
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 fla
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,
> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti
> 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 (curio
+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 Sem
> …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?
Ye, that would be the alternative. We could finalise v5 as it was prior to the
new framing format, then create v6-beta in trunk only with the 15299 changes.
> On 8 Dec 2020, at 11:33, Benedict Elliott Smith wrote:
>
> Perhaps we should skip v5, and move to v6 for the new protocol to avoid this
Perhaps we should skip v5, and move to v6 for the new protocol to avoid this
issue?
On 08/12/2020, 10:53, "Sam Tunnicliffe" wrote:
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a
framing layer around the existing CQL messages. This is targetted at protocol
v5,
CASSANDRA-15299 has revised the wire format of CQL native protocol to add a
framing layer around the existing CQL messages. This is targetted at protocol
v5, which is (still) currently in beta. There's a small problem with this
though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, th
11 matches
Mail list logo
