Hindsight is 20/20. For 8099 this is the reason we cut the 2.2 release before 8099 got merged.
But moving forward with where we are now, if we are going to start adding some experimental flags to things, then I would definitely put SASI on this list as well. For both SASI and MV I don’t know that adding a flags in the cassandra.yaml which prevents their use is the right way to go. I would propose that we emit WARN from the native protocol mechanism when a user does an ALTER/CREATE what ever that tries to use an experiment feature, and probably in the system.log as well. So someone who is starting new development using them will get a warning showing up in cqlsh “hey the thing you just used is experimental, proceed with caution” and also in their logs. These things are live on clusters right now, and I would not want someone to upgrade their cluster to a new *patch* release and suddenly something that may have been working for them now does not function. Anyway, we need to be careful about how this gets put into practice if we are going to do it retroactively. -Jeremiah > On Oct 1, 2017, at 5:36 PM, Josh McKenzie <jmcken...@apache.org> wrote: > >> >> I think committing 8099, or at the very least, parts of it, behind an >> experimental flag would have been the right thing to do. > > With a major refactor like that, it's a staggering amount of extra work to > have a parallel re-write of core components of a storage engine accessible > in parallel to the major based on an experimental flag in the same branch. > I think the complexity in the code-base of having two such channels in > parallel would be an altogether different kind of burden along with making > the work take considerably longer. The argument of modularizing a change > like that, however, is something I can get behind as a matter of general > principle. As we discussed at NGCC, the amount of static state in the C* > code-base makes this an aspirational goal rather than a reality all too > often, unfortunately. > > Not looking to get into the discussion of the appropriateness of 8099 and > other major refactors like it (nio MessagingService for instance) - but > there's a difference between building out new features and shielding the > code-base and users from their complexity and reliability and refactoring > core components of the code-base to keep it relevant. > > On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius <dbros...@apache.org> wrote: > >> triggers >> >> >> On 10/01/2017 11:25 AM, Jeff Jirsa wrote: >> >>> Historical examples are anything that you wouldn’t bet your job on for >>> the first release: >>> >>> Udf/uda in 2.2 >>> Incremental repair - would have yanked the flag following 9143 >>> SASI - probably still experimental >>> Counters - all sorts of correctness issues originally, no longer true >>> since the rewrite in 2.1 >>> Vnodes - or at least shuffle >>> CDC - is the API going to change or is it good as-is? >>> CQL - we’re on v3, what’s that say about v1? >>> >>> Basically anything where we can’t definitively say “this feature is going >>> to work for you, build your product on it” because companies around the >>> world are trying to make that determination on their own, and they don’t >>> have the same insight that the active committers have. >>> >>> The transition out we could define as a fixed number of releases or a dev@ >>> vote, I don’t think you’ll find something that applies to all experimental >>> features, so being flexible is probably the best bet there >>> >>> >>> >> >> --------------------------------------------------------------------- >> 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
