>
> Where I think there becomes a grey area is on refactoring
ISTM we have two types of refactors:
1) Improving logic, tracking, state machines, etc (behavior, invasive)
2) Should be opaque to end user with zero change to behavior (hygiene, code
organization)
Feature flag on #1 as it's kind of a
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 proba
> 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 develo
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
>
> 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 sh
>
> - 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 tabl
>
>
> 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 b
>
> I would move "Deprecating functionality" to be under Minor version.
Good call. I'll get this into a wiki article once we hash it out on thread
here.
consensus requirements were dropped after being noted for patch releases,
> was that intentional?
Hm. With how our project works we should prob
> So to attempt to distill a set of heuristics from the discussion:
>
> Patch release: Goal: maintain and improve stability
> - Non-disruptive, non-API changing bugs are fine w/out consensus
> - Bugs that change defaults or interfaces require consensus
> - Improvements of any kind require consensus
This looks good to me, though consensus requirements were dropped
after being noted for patch releases, was that intentional?
On Wed, Sep 1, 2021 at 12:28 PM Joshua McKenzie wrote:
>
> So to attempt to distill a set of heuristics from the discussion:
>
> Patch release: Goal: maintain and improve
So to attempt to distill a set of heuristics from the discussion:
Patch release: Goal: maintain and improve stability
- Non-disruptive, non-API changing bugs are fine w/out consensus
- Bugs that change defaults or interfaces require consensus
- Improvements of any kind require consensus and must b
Throwing my two cents out…
I'm keen for us to better adhere to SemVer rules (I've said this before).
Specifically defining the difference between a Major and a Minor version,
and defining the difference between a Minor and a Patch version (which in
turn addresses your questions Josh). But this i
12 matches
Mail list logo
