> > Feature flag basically means "experimental" I'm thinking of feature flags more as giving the power to operators to decide what they do and don't allow users of the database access to. Even if a feature is very stable and non-experimental, it can have negative effects on other use-cases on a shared cluster, be incompatible with the underlying execution environment, be outside compliance policies of an organization, require greater expertise to use correctly, etc.
That said, I 100% agree w/you on the "limit it to significant new features". I don't think feature flagging nodetool commands makes a lot of sense. :) Adding it to the CEP template as something to yes/no on would be a simple clarification for this. +1 ~Josh On Thu, Sep 2, 2021 at 3:14 AM Benjamin Lerer <ble...@apache.org> wrote: > > > > - New features, always with feature flag (added; happy to drop if > > controversial) > > > I believe that always having a feature flag for every new feature might be > too complicated in practice for different reasons. > Some new features might be low impact like new nodetool commands or new > virtual tables and adding flags for those might simply be extra > complication for the developers and users. > For some other features it might be simply too hard to hide them behind > feature flags. > > Feature flag basically means "experimental" so it would be good when a > feature flag is introduced to also have a clear plan on when and how the > flag will be removed. > > I would personally limit the feature flag to significant new features. As > those types of features now require a CEP, we could make the feature fag > discussion part of the CEP discussion. > > What do you think? > > > > Le jeu. 2 sept. 2021 à 08:41, Mick Semb Wever <m...@apache.org> a écrit : > > > > > > > > > > There's certainly a lot of complexity in a lot of the systems here, no > > > denying that, so maybe we treat the topic of API changes as "here's > loose > > > guidelines (destructive vs. additive w/sane defaults, etc) but plan to > > take > > > it case-by-case" and be a bit more prescriptive on the "where do bug > > fixes > > > vs. improvements vs. new features go and why"? > > > > > > > > > Agree. > > >
