I see this discussion as several decisions which can be made in small increments.
1. In release cycles, when can we propose a feature to be deprecated or marked experimental. Ideally a new feature should come out experimental if required but we have several who are candidates now. We can work on integrating this in the release lifecycle doc we already have. 2. What is the process of making an existing feature experimental? How does it affect major releases around testing. 3. What is the process of deprecating/removing an experimental feature. (Assuming experimental features should be deprecated/removed) Coming to MV, I think we need more data before we can say we should deprecate MV. Here are some of them which should be part of deprecation process 1.Talk to customers who use them and understand what is the impact. Give them a forum to talk about it. 2. Do we have enough resources to bring this feature out of the experimental feature list in next 1 or 2 major releases. We cannot have too many experimental features in the database. Marking a feature experimental should not be a parking place for a non functioning feature but a place while we stabilize it. On Tue, Jun 30, 2020 at 4:52 PM <joshua.mcken...@gmail.com> wrote: > I followed up with the clarification about unit and dtests for that reason > Dinesh. We test experimental features now. > > If we’re talking about adding experimental features to the 40 quality > testing effort, how does that differ from just saying “we won’t release > until we’ve tested and stabilized these features and they’re no longer > experimental”? > > Maybe I’m just misunderstanding something here? > > > On Jun 30, 2020, at 7:12 PM, Dinesh Joshi <djo...@apache.org> wrote: > > > > > >> > >> On Jun 30, 2020, at 4:05 PM, Brandon Williams <dri...@gmail.com> wrote: > >> > >> Instead of ripping it out, we could instead disable them in the yaml > >> with big fat warning comments around it. That way people already > >> using them can just enable them again, but it will raise the bar for > >> new users who ignore/miss the warnings in the logs and just use them. > > > > Not a bad idea. Although, the real issue is that users enable MV on a 3 > node cluster with a few megs of data and conclude that MVs will > horizontally scale with the size of data. This is what causes issues for > users who naively roll it out in production and discover that MVs do not > scale with their data growth. So whatever we do, the big fat warning should > educate the unsuspecting operator. > > > > Dinesh > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
