Bruce, agreed. I think we should eliminate all the fluff language around "significant improvements". What's "significant" is entirely subjective. I'd prefer to stick to the much simpler definition from semver.org: > > Given a version number MAJOR.MINOR.PATCH, increment the: > > 1. MAJOR version when you make incompatible API changes, > 2. MINOR version when you add functionality in a backwards-compatible > manner, and > 3. PATCH version when you make backwards-compatible bug fixes. > > On Tue, Oct 9, 2018 at 9:03 AM Bruce Schuchardt <bschucha...@pivotal.io> wrote:
> -1 > > To me the definition of major vs minor releases is too muddy. Our > Versioning and Branching > < > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching> > > page has requirements for a Minor release that seem orthogonal to this > discussion. A Minor release "must definitely include significant > improvements to current API or components that justify not be configured > (sic) as /maintenance/ changes". > > The page also describes a Maintenance release that seems to be more what > we're talking about here. > > I think we need a new proposal for Major / Minor / Maintenance release > definitions. That's what we should be voting on. > > > > On 10/8/18 2:24 PM, Alexander Murmann wrote: > > Hi everyone, > > > > As discussed in "Predictable minor release cadence", I'd like us to find > > agreement on releasing a new minor version every three months. There are > > more details in the other thread and I should have captured everything > > relevant on the wiki: > > https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule > > > > There are also some discussions about patch releases. Let's please focus > > this vote on the proposed minor release schedule and carry on other > > discussions in the [DISCUSS] thread. > > > > Thank you all! > > > >
