I think "experimental" isn't very helpful or useful except in the case of MVs. It's like when we said "unsafe assassinate endpoint" - it pretty much meant - don't use this unless you know what you're doing. I don't think new features fall into that category.
As an example, the Java driver docs said that Java 17 support was experimental for a time (nb not the DB, the driver). Some users had requirements to go to Java 17 at their companies but it was labeled experimental. There were no known issues. So there was no planned "once we have this fixed" or "once we have this tested." So the flag is now gone and we are going to fix any problems that come up. However I don't think "beta" is much better. I don't think it should be the path for all new features - I think it should be a case-by-case basis. Going to the next major/minor version in and of itself obviously doesn't make the feature more stable or more production ready. We would need a plan to go from beta to GA presumably with "work out X deficiency before calling it GA." Should SAI be labeled beta? Perhaps, but that actively discourages people from using it in production. And if we say it will be out of beta for 5.1 or 5.1.next, what do we concretely mean will be different? In the case of UCS, is it in a beta state until we resolve the discussions around UX/documentation? From a functional and production usage perspective, it has been the only compaction strategy available for users in DataStax's Astra managed database service in both traditional node based deployments and serverless for 5 years across thousands of databases. While I agree that it's premature to call that a new default for tables, it seems overly cautious to me that it needs to pass through a beta period. Let people opt into it and try it out and if something breaks, let's fix it. I'm not sure of the value of using "beta" with it. I want Apache Cassandra to be a stable database system with all of what that implies. I just think with general rule like this for all new features we're swinging the pendulum a bit too far in the direction of caution. > On Dec 9, 2024, at 11:54 AM, Slater, Ben via dev <dev@cassandra.apache.org> > wrote: > > I'm a little worried by the idea of grouping in MVs with things like a Java > version under the same "beta" label (acknowledging that they are currently > grouped under the same "experimental" label). > > To me, "beta" implies it's pretty close to production ready and there is an > intention to get it to production ready in the near future. I don't think > this really describes MVs as I don't see anyone looking like they are trying > to get them to really production ready (although I could easily be wrong on > that). > > Maybe there is an argument for "experimental"=this is here to get feedback > but there's no commitment it will make it to production ready and "beta"=we > think this is done but we'd like to see some production use before declaring > it stable. For beta, we'll treat bugs with the same priority as "stable" (or > at least close to)? > > Cheers > Ben > > > From: Jon Haddad <j...@rustyrazorblade.com <mailto:j...@rustyrazorblade.com>> > Sent: 09 December 2024 09:43 > To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> > <dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>> > Subject: Re: [DISCUSS] Experimental flagging (fork from Re-evaluate > compaction defaults in 5.1/trunk) > > EXTERNAL EMAIL - USE CAUTION when clicking links or attachments > > > > I like this. There's a few things marked as experimental today, so I'll take > a stab at making this more concrete, and I think we should be open to > graduating certain things out of beta to GA at a faster cycle than a major > release. > > Java versions, for example, should really move out of "beta" quickly. We > test against it, and we're not going to drop new versions. So if we're > looking at C* 5.0, we should move Java 17 out of experimental / beta > immediately and call it GA. > > SAI and UCS should probably graduate no later than 5.1. > > On the other hand, MVs have enough warts I actively recommend against using > them and should be in beta till we can actually repair them. > > I don't know if anyone's actually used transient replication and if it's even > beta quality... that might actually warrant being called experimental still. > > 'ALTER ... DROP COMPACT STORAGE' is flagged as experimental. I'm not sure > what to do with this. I advise people migrate their data for any Thrift -> > CQL cases, mostly because the edge cases are so hard to know in advance, > especially since by now these codebases are ancient and the original > developers are long gone. > > Thoughts? > > Jon > > > > > On Mon, Dec 9, 2024 at 6:28 AM Josh McKenzie <jmcken...@apache.org > <mailto:jmcken...@apache.org>> wrote: > Jon stated: >> Side note: I think experimental has been over-used and has lost all meaning. >> How is Java 17 experimental? Very confusing for the community. > > Dinesh followed with: >> Philosophically, as a project, we should wait until critical features like >> these reach a certain level of maturity prior to recommending it as a >> default. For me maturity is a function of adoption by diverse use-cases in >> production and scale. > > I'd like to discuss 2 ideas related to the above: > We rename / alias "experimental" to "beta". It's a word that's ubiquitous in > our field and communicates the correct level of expectation to our users (API > stable, may have bugs) > All new features go through one major (either semver MAJOR or MINOR) as "beta" > > To Jon's point, "experimental" was really a kludge to work around > Materialized Views having some very sharp edges that users had to be very > aware of. We haven't really used the flagging much (at all?) since then, and > we don't have a formalized way to shepherd a new feature through a "soak" > period where it can "reach a certain level of maturity". We're caught in a > chicken-or-egg scenario with our current need to get a feature released more > broadly to have confidence in its stability (to Dinesh's point). > > In my mind, the following feature evolution would be healthy for us and good > for our users: > Beta > Generally Available > Default (where appropriate) > To graduate from Beta -> GA, good UX, user facing documentation, a [DISCUSS] > thread where we have a clear consensus of readiness, all seem like healthy > and good steps. From GA -> Default, [DISCUSS] like we're having re: > compaction strategies, unearthing shortcomings, edge-cases, documentation > needs, etc. > > Curious what others think. > > ~Josh
