Seems reasonable, especially since we're in alpha mode. On Wed, Oct 9, 2019 at 10:28 AM Aleksey Yeshchenko <alek...@apple.com.invalid> wrote:
> +1; in particular since the protocol itself is still in beta > > > On 9 Oct 2019, at 17:26, Oleksandr Petrov <oleksandr.pet...@gmail.com> > wrote: > > > > Hi, > > > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > > release. Many (minor) features and changes suggested during that time are > > possible to implement in 4.next without any problem. However, some > changes > > that seem to be very important for the community, which got mentioned in > > several conversations, are not possible to implement without protocol > > changes. By *protocol* changes here I mean both native and client > protocol. > > > > Here's a shortlist of the issues in question: > > https://issues.apache.org/jira/browse/CASSANDRA-15349 Add “Going away” > > message to the client protocol > > https://issues.apache.org/jira/browse/CASSANDRA-15350 Add CAS > “uncertainty” > > and “contention" messages that are currently propagated as a > > WriteTimeoutException. > > https://issues.apache.org/jira/browse/CASSANDRA-15351 Allow configuring > > timeouts on the per-request basis > > https://issues.apache.org/jira/browse/CASSANDRA-15352 Replica failure > > propagation to coordinator and client > > https://issues.apache.org/jira/browse/CASSANDRA-15299 Improve > checksumming > > and compression in protocol v5-beta > > > > And, less importantly - CASSANDRA-14683 (paging state issue). > > > > My suggestion would be to lift a freeze for all (or at least some) of > these > > issues, since they seem to be quite important for operators and each one > of > > them is extremely low risk, which means that any validation effort that > has > > already happened won't have to be re-done. All of the issues are fairly > > easy to implement, which means they won't delay the release. > > > > To my best knowledge, there's no client that fully supports 4.0, I think > > doing this now actually makes sense, meaning that driver implementers > won't > > really have to redo anything. > > > > Your thoughts on this are welcome, > > -- Alex > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
