Looking at the current definition it sounds like we can only decide if its a Minor at the time of release and cannot be scheduled. Thoughts?
*> MINOR*: Minor releases can contain minor new features and must definitely include significant improvements > to current API or components that justify not be configured as *maintenance* changes. Minor releases can also > be increased if extensions or sub-projects add new features or are updated somehow. On Wed, Oct 10, 2018 at 9:35 AM Anthony Baker <aba...@pivotal.io> 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 > >
