Re: [VOTE] Time-based release schedule for minor releases

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

Re: [VOTE] Time-based release schedule for minor releases

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 a

Re: [VOTE] Time-based release schedule for minor releases

If you look through the 350+ JIRA’s fixed for 1.7.0 it’s not only bug fixes—there are improvements and new additions. IMO, using a Minor version designation was the correct choice and fits with semver guidelines. Anthony > On Oct 10, 2018, at 10:31 AM, Robert Houghton wrote: > > Alexander,

Re: [VOTE] Time-based release schedule for minor releases

Sure! I am all in for time-based releases. I see the point that we can only do Minors as patches(or maintenance) are reserved for hotfixes and security bugs. So +1 for a time-based release to ship whatever has changed since the last release. On Wed, Oct 10, 2018 at 10:29 AM Alexander Murmann wro

Re: [VOTE] Time-based release schedule for minor releases

Alexander, how can you say never? Didn't we just go through a time like this? On Wed, Oct 10, 2018, 10:29 Alexander Murmann wrote: > Sai, I think what you are saying is theoretically 100% correct. As Anthony > points out in practice we'd never go for three months without a single > feature. > >

Re: [VOTE] Time-based release schedule for minor releases

Sai, I think what you are saying is theoretically 100% correct. As Anthony points out in practice we'd never go for three months without a single feature. I think it makes sense to agree to aim for the quarterly release being a minor release as opposed to aiming for a patch or major. If we aimed f

Re: [VOTE] Time-based release schedule for minor releases

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

Re: [VOTE] Time-based release schedule for minor releases

+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 lea

Re: [VOTE] Time-based release schedule for minor releases

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] h

Re: [VOTE] Time-based release schedule for minor releases

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

Re: [VOTE] Time-based release schedule for minor releases

+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 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.

Re: [VOTE] Time-based release schedule for minor releases

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 def

Re: [VOTE] Time-based release schedule for minor releases

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

Re: [VOTE] Time-based release schedule for minor releases

-1 To me the definition of major vs minor releases is too muddy.  Our Versioning and Branching page has requirements for a Minor release that seem orthogonal to this discussion.  A Minor release "must definitely incl

Re: [VOTE] Time-based release schedule for minor releases

+1 for 3-month minor release schedule > On Oct 9, 2018, at 12:32 AM, Juan José Ramos wrote: > > +1 for time-based releases. > > On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz wrote: > >> +1 Quarterly releases >> >> -- >> Mike Stolz >> Principal Engineer - Gemfire Product Manager >> Mobile: 63

Re: [VOTE] Time-based release schedule for minor releases

+1 for time-based releases. On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz wrote: > +1 Quarterly releases > > -- > Mike Stolz > Principal Engineer - Gemfire Product Manager > Mobile: 631-835-4771 > > On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" > wrote: > > > +1 for time-based minors (if patches ar

Re: [VOTE] Time-based release schedule for minor releases

+1 Quarterly releases -- Mike Stolz Principal Engineer - Gemfire Product Manager Mobile: 631-835-4771 On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" wrote: > +1 for time-based minors (if patches are reserved for security fixes) > > On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker wrote: > > > We reserv

Re: [VOTE] Time-based release schedule for minor releases

+1 for time-based minors (if patches are reserved for security fixes) On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker wrote: > We reserve the patch version number for when we want to issue a fix for a > security vulnerability or address a critical bug. We did that with 1.1.1 > and 1.2.1. > > I thi

Re: [VOTE] Time-based release schedule for minor releases

+1 for time-based releases. I think we would do well to gain some discipline around releasing on a predictable cadence. We're probably never going to be short on changes that are 'worthy' of going out on a release which, too often, simply lead to the release being stretched out as we add in Just O

Re: [VOTE] Time-based release schedule for minor releases

We reserve the patch version number for when we want to issue a fix for a security vulnerability or address a critical bug. We did that with 1.1.1 and 1.2.1. I think the release schedule and SemVer are separate topics. AFAICT this proposal is just about putting a more deterministic schedule a

Re: [VOTE] Time-based release schedule for minor releases

-0 It seems we have completely disregarded the *patch* version number. Does this mean Geode versions will be *major*,*minor*? Can we then remove the *patch* version on the release version? In addition to this, should the test coverage not be sufficient enough to allow "release when green"? I

Re: [VOTE] Time-based release schedule for minor releases

+0 My preference would be for - time-based patches and - scope based minors & majors On Mon, Oct 8, 2018 at 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 month

Re: [VOTE] Time-based release schedule for minor releases

+1 On Mon, Oct 8, 2018 at 2:27 PM Jacob Barrett wrote: > +0 > > My preference is to release when there is something worth releasing rather > than arbitrary points in time but I don't hold that preference strongly > enough to spike this effort. > > On Mon, Oct 8, 2018 at 2:24 PM Alexander Murmann

Re: [VOTE] Time-based release schedule for minor releases

+0 My preference is to release when there is something worth releasing rather than arbitrary points in time but I don't hold that preference strongly enough to spike this effort. On Mon, Oct 8, 2018 at 2:24 PM Alexander Murmann wrote: > Hi everyone, > > As discussed in "Predictable minor releas

[VOTE] Time-based release schedule for minor releases

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/GE