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: 1. 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) 2. *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: 1. Beta 2. Generally Available 3. 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
