I’m with Sai that it seems like we need to clear up our definitions of minor versus patch releases. The referenced SemVer definition indicates that any backwards compatible bug fix qualifies for a patch release. But it was stated earlier that only security-related or critidal bug fixes justify a patch release. I personally prefer SemVer’s definition, but it’s up for debate.
Perhaps we can do 3-month release cycles, and determine whether the release would be patch or minor based on the changes added since the last release (bug fixes vs new functionality). Ryan On Wed, Oct 10, 2018 at 7:48 AM Addison Huddy <ahu...@pivotal.io> wrote: > +1 for a cadence based release cycle that using 3-month between minor > releases. > > On Wed, Oct 10, 2018 at 7:29 AM Sai Boorlagadda <sai.boorlaga...@gmail.com > > > wrote: > > > After looking at these definitions are we not talking about time-based > > patch releases? > > It is again subjective how much functionality makes a MINOR release. > > > > Though this thread is seeking consensus on time-based scheduled it is > > specifically for minors. > > it appears to me like we need to update our definitions before we make a > > decision on schedule. > > > > On Tue, Oct 9, 2018 at 10:06 AM Alexander Murmann <amurm...@pivotal.io> > > wrote: > > > > > 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! > > > > > > > > > > > > > > > > > > >
