> > 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 probably drop the verbiage entirely since everything requires at least a lazy consensus? Definitely not intended as a delta. I think it's easy for us to > look at it solely from a code and accuracy perspective, but that it would > be more valuable to take a user-centric (WIIFM) approach and to be as > pragmatic as possible Agree with the general sentiment; there's a balance we need to strike here between highly clear elucidation of rules and heuristics and leaving people "wiggle room" to navigate outside those guidelines. We have quite a few active committers and even more community members now (and hope to keep growing that!), and for a newcomer on a project with a question of "what fixversion should I put change X in", an answer of "it depends; check with a committer" is something we should do our best to avoid and instead empower folks as best we can. 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"? wdyt? ~Josh On Wed, Sep 1, 2021 at 5:04 PM Mick Semb Wever <m...@apache.org> wrote: > > 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 be small, in safe > > areas, non default changing > > > > Minor release: Goal: stable introduction of new features > > - New features, always with feature flag (added; happy to drop if > > controversial) > > - No API breaking changes; additive API changes w/sane defaults > acceptable > > > > Major release: Goal: provide avenue to make breaking, non-backwards > > compatible evolutionary changes > > - API breaking changes > > - Deprecating functionality > > - Changing default behaviors > > - Destructive / removing changes (params, features, etc) > > - Major, well-tested and well documented component refactors (added; > happy > > to drop if controversial) > > > > With the above structure, we may go from Major to patches to Major > without > > a Minor, or go from Minor to patches for awhile to Minors if we don't > have > > destructive changes. > > > > Is that consistent w/what you're saying above Mick? If so - what do > others > > think? > > > > > Yes, thanks Josh. > > I do think there's a lot of ambiguity and discussion to be had around what > constitutes a Major change. And, to stress it, I think it's easy for us to > look at it solely from a code and accuracy perspective, but that it would > be more valuable to take a user-centric (WIIFM) approach and to be as > pragmatic as possible. e.g. let's take the discussions whether certain > interfaces/APIs are user-facing enough to signal a major change to all > users (index, triggers, etc, come to mind), bearing in mind our mix-version > upgrade ability deals with a lot (and the planned work raised to deal more > easily with rolling back a started upgrade), us having a NEWS.txt, and that > small API stuff is often changing in minor versions anyway. > > I would move "Deprecating functionality" to be under Minor version. > Something could be deprecated in 4.1, and then removed in 5.0. >
