I don’t think we can or we should cover every particular case but this is a good baseline/guideline and we should encourage people to hit the mailing list when there is uncertainty. My understanding is that this document will support also the initially mentioned one where I saw something that probably partially addresses David’s concerns but it is said as something tbd as far as I understand: https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
“Compatibility between major versions - Content we have so far based on the feedback - Developer community will try not to make any backwards incompatible changes as much as possible, except in extreme cases like to ensure correctness. Introducing a backward incompatibility change needs dev community approval via voting [voting open for 48 hours].” On Fri, 10 Sep 2021 at 14:29, David Capwell <dcapw...@apple.com.invalid> wrote: > > 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? > > Personally I run with the idea we should default to “you need a feature > flag” and special case places which do not need; if we start with > “significant new feature” every feature will be argued that it isn’t > “significant enough” or that offering one would be “too complex”. I would > argue tables/nodetool act more like a feature flag so these examples > shouldn’t cause us to weaken the notation of a feature flag, as they do not > impact you unless you opt-into them…. which is what a feature flag does. > > > For some other features it might be simply too hard to hide them behind > > feature flags. > > In my experience these types of features get a feature flag after the fact > or warned to operators/users not to use them… While working on > CASSANDRA-16850 it was really annoying to support flags as I need to keep > track of state both at the coordinator and the replica to support this, and > at each check’s level (we also do not have a notion of a query context or > what actor is doing the action… which makes this even more painful to do); > this drastically increased my testing scope. This was still important to > do as after it is deployed it could cause a negative impact to operators or > users, so being able to act without code changes is important. > > Where I think there becomes a grey area is on refactoring… for example I > have put in a lot of work refactoring repair coordination and I plan to do > a lot more… do I support falling back to old logic or old behavior? In > CASSANDRA-16909 I document a lot of places which are buggy and have shown > to cause production issues… is the “fix” actually a “new feature” (fun > example that happens on prod from time to time… we drop the merkle tree and > hang forever… we could make this recoverable but is that a feature or a bug > fix)? Should this go into a prior release? > > > > On Sep 10, 2021, at 9:25 AM, Joshua McKenzie <jmcken...@apache.org> > wrote: > > > > I put together a gdoc documenting what was in this thread - should be > open > > to comment for everyone: > > > https://docs.google.com/document/d/1LhCNcbuhtqTkv_aKx1TQUgWEcq022fsAZs1C_oOxEJw/edit > > > > I'll let this thread sit to early next week and assuming no major > concerns > > we'll get that into either the wiki or the site or both. > > > > Thanks everyone for the feedback! > > > > ~Josh > > > > On Thu, Sep 2, 2021 at 9:57 AM Joshua McKenzie <jmcken...@apache.org> > wrote: > > > >> 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. > >>>> > >>> > >> > >
