I see value in using a beta flag in addition to an experimental flag, and that such a beta flag should see a lot more use than experimental.
Java 17 definitely falls in the beta category. I/We definitely recommend its usage in production, but as has been said data is needed over trust and the community hasn't the resources to provide such data – we're just waiting for any user to give us the feedback "we're using it prod". (My expectations were that we'd hear this by 5.0.3.) Early integration is valuable sometimes, and anything marked experimental (once we have a beta flag in use) should be able to later become deprecated and removed. So I agree with Dinesh's point, that also emphasises a high bar for merging – totally agree that we've seen a number of things merged that missed basic testing requirements. A possibility with SAI is to mark it beta while also marking 2i as deprecated (and leaving SASI as marked). This sends a clear signal (imho) that SAI is the recommended solution forward but also being honest about its maturity and QA. On Tue, 10 Dec 2024 at 09:42, Jon Haddad <j...@rustyrazorblade.com> wrote: > > I am strongly against early integration, because we can't / don't remove > things when we should. MVs are the prime example here, as is the current > iteration of Vector search. > > Early integration works fine when it's internal software that you have > control over, it doesn't work well for software that gets deployed and relied > on outside your org. > > > > On Mon, Dec 9, 2024 at 2:02 PM Dinesh Joshi <djo...@apache.org> wrote: >> >> On Mon, Dec 9, 2024 at 12:26 PM Jon Haddad <j...@rustyrazorblade.com> wrote: >>> >>> I hope I've made my point. The bar for merging in new functionality should >>> be higher. Features should work with 1TB of data on 3 nodes, that's a low >>> bar. I've spent at least a thousand hours over the last 5 years developing >>> the tooling to do these tests, there's no reason to not do them, and when >>> we know things are broken, we shouldn't ship them. >> >> >> I am a big fan of early integration. I agree that the bar for merging should >> be high but at the same time we should lean more heavily on feature flagging >> which is also a very common software industry practice. This would allow an >> operator to enable features that are deemed risky for production use. It >> creates a faster feedback loop and will reveal issues earlier in the >> development cycle. It might actually avoid big patches but that is a topic >> for a different thread. >> >> Dinesh
