+0 Willing to try any reaonable plan that emerges. Would like to see some articulation of an "upgrade policy" if such things exist in the open source universe. That is, will each quarterly (or whatever) release necessarily be backward compatible with the previous release? Will a user be able to leapfrog a year's worth of releases at one go, or will they have to step through a chain of consecutive releases one-by-one? Or is that simply not an issue in an open source context?
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 > >
