CASSANDRA-15146 and CASSANDRA-14825 both can be rolled out and be backwards compatible, so 4.0 vs 4.1 is fine to me CASSANDRA-15299 - this should be a blocker for v5, so if this was punted out of 4.0 for any reason, we should also disable v5 protocol. About it being a blocker for beta, since this would break the API, it has to be done pre-beta. Anything which relies on v5 should also be disabled and removed from user facing docs. Given this, I am more in favor of keeping it in 4.0
> The top 5 > drivers alone see tens of thousands of aggregate downloads a day; getting > all 5 of those in parity w/the new featureset and to be tested during the > GA phase is going to be very difficult with driver impacting, significant > protocol changes this late in the alpha cycle (this would argue for them > being pushed to 4.1; including here just to point out the ambivalent PoV > here) For 14825 it would expose a way for clients to learn the schema without needing to know how we store the schema, which should make it less brittle the next time the implementation changes; given that this would be optional to clients, I don’t see why clients can’t migrate to this at their own rate. 15299 is an interface breaking change, but for a new interface that has not yet been released; given the fact v4 is still supported, clients can migrate over time. Clients have a decoupled life cycle from Apache Cassandra, and the features in question are optional for clients, so I find it reasonable that clients migrate at their own rate. As long as we don’t break the existing APIs, I don’t see why client implementations must be a blocker for Apache Cassandra to release. > That > said, trying to put myself in the shoes of an end user that hasn't seen a > material functionality upgrade in 3+ years and could be testing out and > using zero-copy streaming, audit logging, the new messaging service code, > and the hundreds of bugfixes and almost 300 improvements already in 4.0 - I > think the value in getting this release in my hands would outweigh the > value in getting these three particular features in 4.0 vs. 4.1. The biggest body of work I know of is testing and the fact we are missing a lot of tests currently. Given this, the biggest effort remaining is working down this and resolving issues found; so punting these features don’t really get 4.0.0 released any faster. If we want 4.0.0 out faster, the biggest gains would be to get the test plans written up and get more people working on automated testing. > On Jun 16, 2020, at 9:13 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > > I wanted to open up a discussion about optionality of a few tickets for > 4.0. The three I'm specifically thinking of here are: > 1) CASSANDRA-15146: Transition TLS server configuration options are overly > complex > 2) CASSANDRA-14825: Expose table schema for drivers > 3) CASSANDRA-15299: CASSANDRA-13304 follow-up: improve checksumming and > compression in protocol v5-beta > > I am *personally* of the opinion that each of these three should be > considered optional for 4.0 and not blockers to cut beta. My reasoning: > 1) it's been 4 years, 7 months, 11 days since the release of 3.0.0 > 2) Alternatively, it's been 3 years, 4 months, 13 days since the release of > 3.10.0 (the last time we added new features to the DB) > 3) 2 of the 3 tickets involve non-trivial changes to the drivers. The top 5 > drivers alone see tens of thousands of aggregate downloads a day; getting > all 5 of those in parity w/the new featureset and to be tested during the > GA phase is going to be very difficult with driver impacting, significant > protocol changes this late in the alpha cycle (this would argue for them > being pushed to 4.1; including here just to point out the ambivalent PoV > here) > 4) If we plan on releasing 4.1 six months after the release of 4.0 (i.e. > calender scope vs. feature scope - not yet agreed upon but an option), we > would be looking at a relatively trivial delay of the addition of > "nice-to-have" features relative to broader infrastructure adoption cycles. > > I know this is a controversial topic, and I've spoken with many of you that > are working on or reviewing the above tickets - your points of view and > arguments in favor of keeping them in 4.0 definitely resonate with me. That > said, trying to put myself in the shoes of an end user that hasn't seen a > material functionality upgrade in 3+ years and could be testing out and > using zero-copy streaming, audit logging, the new messaging service code, > and the hundreds of bugfixes and almost 300 improvements already in 4.0 - I > think the value in getting this release in my hands would outweigh the > value in getting these three particular features in 4.0 vs. 4.1. > > Also, to reiterate, I would personally advocate for these three tickets > being *optional*, meaning if we merge the 1 awaiting review and 5 in > review, then we push them to 4.1. > > So - what does everyone else think? > > ~Josh --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
