To my mind, one of the core reasons for SemVer is to communicate the level of estimated risk to users when taking an update. It seems to me that the amount of code change included in a quarterly release will always introduce more risk than a single narrowly-targeted fix for a CVE (like those that we have previously released in patch versions). Moreover, the introduction of "substantial new functionality or improvments" is a *sufficient* condition for incrementing minor versions, but is not a *necessary* condition. For these reasons, I vote +1 to aim for quarterly at-least-minor releases.
On Wed, Oct 10, 2018 at 11:17 AM Bruce Schuchardt <bschucha...@pivotal.io> wrote: > Practically speaking I think I agree with Anthony. I'm changing my vote > to +0 but I do still feel that we're not going to be following the > spirit of our major/minor/patch definitions. A quarterly release might > be a Minor release or it might be a Patch release, depending on whether > there are actually any functional changes. We should change those > definitions to match what we're actually doing. > > > On 10/10/18 9:35 AM, Anthony Baker wrote: > > Practically speaking, a quarterly release cycle means there’s *always* > some feature addition or improvement included in the release. That’s why I > agree with the suggestion of a release cadence based on minor version > bumps. See [1] for the outcome of prior discussions on SemVer. > > > > Anthony > > > > [1] > https://cwiki.apache.org/confluence/display/GEODE/Versioning+and+Branching > > > > > >> On Oct 10, 2018, at 8:44 AM, Ryan McMahon <mcmellaw...@apache.org> > wrote: > >> > >> 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 > >
