> 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 be harder to do in drivers since usually they're offering backward-compatible APIs; maybe there we could deprecate `allowBetaVersions` and introduce `allowDevelopmentVersions`. On Tue, Dec 15, 2020 at 6:29 PM Sam Tunnicliffe <s...@beobal.com> wrote: > > 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 <m...@apache.org> wrote: > > > >> > >> 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. For example, an extra > > sentence at > > > https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L140-L142 > > > > And it would also be awesome to see this on the website docs. It's a bit > of > > tribal knowledge and crawling jira tickets atm. > > > > I think it can also be made more explicit here by what we mean by > "matching > > server and client versions". To my understanding this is not explicit > > versions within V5, as there is only that, but just > > different build/implementation versions. And that this basically also > means > > mixed server versions are outside the scope of the beta flag. > > > > 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. > > > > > >> +1 to have 4.0 with v5. > > > > > > I agree, v6 is not needed. What's the verdict now for CASSANDRA-14973 ? > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- alex p
