You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Alexander Murmann <am...@pivotal.io> on 2018/10/08 21:24:15 UTC
[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/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!
Re: [VOTE] Time-based release schedule for minor releases
Posted by Anthony Baker <ab...@pivotal.io>.
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 <rh...@pivotal.io> wrote:
>
> 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 <am...@pivotal.io> 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.
>>
>> 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 for a
>> patch or major, this would likely impact our branching strategy. Breaking
>> changes would be permitted for a major and we'd need to think about how to
>> work with a support branch for the previous major etc. If we aimed for a
>> patch we couldn't merge features, etc.
Re: [VOTE] Time-based release schedule for minor releases
Posted by Robert Houghton <rh...@pivotal.io>.
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 <am...@pivotal.io> 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.
>
> 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 for a
> patch or major, this would likely impact our branching strategy. Breaking
> changes would be permitted for a major and we'd need to think about how to
> work with a support branch for the previous major etc. If we aimed for a
> patch we couldn't merge features, etc.
>
> On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > 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 <ab...@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 <mc...@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
> > >
> > >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <am...@pivotal.io>
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.
>
> 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 for a
> patch or major, this would likely impact our branching strategy. Breaking
> changes would be permitted for a major and we'd need to think about how to
> work with a support branch for the previous major etc. If we aimed for a
> patch we couldn't merge features, etc.
>
> On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda <
> sai.boorlagadda@gmail.com>
> wrote:
>
> > 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 <ab...@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 <mc...@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
> > >
> > >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Alexander Murmann <am...@pivotal.io>.
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 for a
patch or major, this would likely impact our branching strategy. Breaking
changes would be permitted for a major and we'd need to think about how to
work with a support branch for the previous major etc. If we aimed for a
patch we couldn't merge features, etc.
On Wed, Oct 10, 2018 at 10:17 AM Sai Boorlagadda <sa...@gmail.com>
wrote:
> 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 <ab...@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 <mc...@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
> >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <ab...@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 <mc...@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
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Dave Barnes <db...@pivotal.io>.
+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 <ab...@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 <mc...@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
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Jared Stewart <st...@gmail.com>.
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 <bs...@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 <mc...@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
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <mc...@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
Re: [VOTE] Time-based release schedule for minor releases
Posted by Anthony Baker <ab...@pivotal.io>.
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 <mc...@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
Re: [VOTE] Time-based release schedule for minor releases
Posted by Ryan McMahon <mc...@apache.org>.
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 <ah...@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.boorlagadda@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 <am...@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 <
> bschuchardt@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!
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Addison Huddy <ah...@pivotal.io>.
+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 <sa...@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 <am...@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 <bs...@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!
> > > >
> > >
> > >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <am...@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 <bs...@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!
> > >
> >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Alexander Murmann <am...@pivotal.io>.
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 <bs...@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!
> >
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Bruce Schuchardt <bs...@pivotal.io>.
-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!
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Sai Boorlagadda <sa...@gmail.com>.
+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 <am...@pivotal.io>
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!
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Kenneth Howe <kh...@pivotal.io>.
+1 for 3-month minor release schedule
> On Oct 9, 2018, at 12:32 AM, Juan José Ramos <jr...@pivotal.io> wrote:
>
> +1 for time-based releases.
>
> On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz <ms...@pivotal.io> wrote:
>
>> +1 Quarterly releases
>>
>> --
>> Mike Stolz
>> Principal Engineer - Gemfire Product Manager
>> Mobile: 631-835-4771
>>
>> On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" <sa...@gmail.com>
>> wrote:
>>
>>> +1 for time-based minors (if patches are reserved for security fixes)
>>>
>>> On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker <ab...@pivotal.io> 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 think the release schedule and SemVer are separate topics. AFAICT
>> this
>>>> proposal is just about putting a more deterministic schedule around
>> what
>>> we
>>>> are already doing / have been doing. Given that releases have
>>> significant
>>>> overhead, I think it makes sense to plan ahead. If you want to know
>> more
>>>> about that ask Naba, the last release manager :-)
>>>>
>>>>
>>>> Anthony
>>>>
>>>>
>>>>> On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
>>>>>
>>>>> -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 must agree with @Jacob, I would prefer
>>>> something a lot less formalized. If the community has contributed a
>>>> significant fix, should that not warrant an ad-hoc patch release? Or
>> what
>>>> if the community has added functionality, that could "fill" a single
>>> minor
>>>> release by itself, should that not warrant a pre-emptive release.
>>>>>
>>>>> All these questions are not enough to warrant this effort to be
>>> blocked,
>>>> but I prefer those use cases to be considered for a more comprehensive
>>>> documentation effort, than what is currently on the wiki.
>>>>>
>>>>> In addition to that, is a release with only bug fixes in it, really
>>>> still a worthy of minor release number, or does it not count as a patch
>>>> release?
>>>>>
>>>>> --Udo
>>>>>
>>>>>
>>>>> On 10/8/18 14:27, 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 <
>> amurmann@pivotal.io
>>>>
>>>>>> 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!
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Juan José Ramos Cassella
> Senior Technical Support Engineer
> Email: jramos@pivotal.io
> Office#: +353 21 4238611
> Mobile#: +353 87 2074066
> After Hours Contact#: +1 877 477 2269
> Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
> How to upload artifacts:
> https://support.pivotal.io/hc/en-us/articles/204369073
> How to escalate a ticket:
> https://support.pivotal.io/hc/en-us/articles/203809556
>
> [image: support] <https://support.pivotal.io/> [image: twitter]
> <https://twitter.com/pivotal> [image: linkedin]
> <https://www.linkedin.com/company/3048967> [image: facebook]
> <https://www.facebook.com/pivotalsoftware> [image: google plus]
> <https://plus.google.com/+Pivotal> [image: youtube]
> <https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Juan José Ramos <jr...@pivotal.io>.
+1 for time-based releases.
On Tue, Oct 9, 2018 at 12:02 AM Michael Stolz <ms...@pivotal.io> wrote:
> +1 Quarterly releases
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" <sa...@gmail.com>
> wrote:
>
> > +1 for time-based minors (if patches are reserved for security fixes)
> >
> > On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker <ab...@pivotal.io> 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 think the release schedule and SemVer are separate topics. AFAICT
> this
> > > proposal is just about putting a more deterministic schedule around
> what
> > we
> > > are already doing / have been doing. Given that releases have
> > significant
> > > overhead, I think it makes sense to plan ahead. If you want to know
> more
> > > about that ask Naba, the last release manager :-)
> > >
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
> > > >
> > > > -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 must agree with @Jacob, I would prefer
> > > something a lot less formalized. If the community has contributed a
> > > significant fix, should that not warrant an ad-hoc patch release? Or
> what
> > > if the community has added functionality, that could "fill" a single
> > minor
> > > release by itself, should that not warrant a pre-emptive release.
> > > >
> > > > All these questions are not enough to warrant this effort to be
> > blocked,
> > > but I prefer those use cases to be considered for a more comprehensive
> > > documentation effort, than what is currently on the wiki.
> > > >
> > > > In addition to that, is a release with only bug fixes in it, really
> > > still a worthy of minor release number, or does it not count as a patch
> > > release?
> > > >
> > > > --Udo
> > > >
> > > >
> > > > On 10/8/18 14:27, 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 <
> amurmann@pivotal.io
> > >
> > > >> 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!
> > > >>>
> > > >
> > >
> > >
> >
>
--
Juan José Ramos Cassella
Senior Technical Support Engineer
Email: jramos@pivotal.io
Office#: +353 21 4238611
Mobile#: +353 87 2074066
After Hours Contact#: +1 877 477 2269
Office Hours: Mon - Thu 08:30 - 17:00 GMT. Fri 08:30 - 16:00 GMT
How to upload artifacts:
https://support.pivotal.io/hc/en-us/articles/204369073
How to escalate a ticket:
https://support.pivotal.io/hc/en-us/articles/203809556
[image: support] <https://support.pivotal.io/> [image: twitter]
<https://twitter.com/pivotal> [image: linkedin]
<https://www.linkedin.com/company/3048967> [image: facebook]
<https://www.facebook.com/pivotalsoftware> [image: google plus]
<https://plus.google.com/+Pivotal> [image: youtube]
<https://www.youtube.com/playlist?list=PLAdzTan_eSPScpj2J50ErtzR9ANSzv3kl>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Michael Stolz <ms...@pivotal.io>.
+1 Quarterly releases
--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Oct 8, 2018 6:52 PM, "Sai Boorlagadda" <sa...@gmail.com> wrote:
> +1 for time-based minors (if patches are reserved for security fixes)
>
> On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker <ab...@pivotal.io> 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 think the release schedule and SemVer are separate topics. AFAICT this
> > proposal is just about putting a more deterministic schedule around what
> we
> > are already doing / have been doing. Given that releases have
> significant
> > overhead, I think it makes sense to plan ahead. If you want to know more
> > about that ask Naba, the last release manager :-)
> >
> >
> > Anthony
> >
> >
> > > On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
> > >
> > > -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 must agree with @Jacob, I would prefer
> > something a lot less formalized. If the community has contributed a
> > significant fix, should that not warrant an ad-hoc patch release? Or what
> > if the community has added functionality, that could "fill" a single
> minor
> > release by itself, should that not warrant a pre-emptive release.
> > >
> > > All these questions are not enough to warrant this effort to be
> blocked,
> > but I prefer those use cases to be considered for a more comprehensive
> > documentation effort, than what is currently on the wiki.
> > >
> > > In addition to that, is a release with only bug fixes in it, really
> > still a worthy of minor release number, or does it not count as a patch
> > release?
> > >
> > > --Udo
> > >
> > >
> > > On 10/8/18 14:27, 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 <amurmann@pivotal.io
> >
> > >> 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!
> > >>>
> > >
> >
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Sai Boorlagadda <sa...@gmail.com>.
+1 for time-based minors (if patches are reserved for security fixes)
On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker <ab...@pivotal.io> 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 think the release schedule and SemVer are separate topics. AFAICT this
> proposal is just about putting a more deterministic schedule around what we
> are already doing / have been doing. Given that releases have significant
> overhead, I think it makes sense to plan ahead. If you want to know more
> about that ask Naba, the last release manager :-)
>
>
> Anthony
>
>
> > On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
> >
> > -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 must agree with @Jacob, I would prefer
> something a lot less formalized. If the community has contributed a
> significant fix, should that not warrant an ad-hoc patch release? Or what
> if the community has added functionality, that could "fill" a single minor
> release by itself, should that not warrant a pre-emptive release.
> >
> > All these questions are not enough to warrant this effort to be blocked,
> but I prefer those use cases to be considered for a more comprehensive
> documentation effort, than what is currently on the wiki.
> >
> > In addition to that, is a release with only bug fixes in it, really
> still a worthy of minor release number, or does it not count as a patch
> release?
> >
> > --Udo
> >
> >
> > On 10/8/18 14:27, 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 <am...@pivotal.io>
> >> 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!
> >>>
> >
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Jens Deppe <jd...@pivotal.io>.
+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 One More Thing.
_-Jens
On Mon, Oct 8, 2018 at 2:55 PM Anthony Baker <ab...@pivotal.io> 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 think the release schedule and SemVer are separate topics. AFAICT this
> proposal is just about putting a more deterministic schedule around what we
> are already doing / have been doing. Given that releases have significant
> overhead, I think it makes sense to plan ahead. If you want to know more
> about that ask Naba, the last release manager :-)
>
>
> Anthony
>
>
> > On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
> >
> > -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 must agree with @Jacob, I would prefer
> something a lot less formalized. If the community has contributed a
> significant fix, should that not warrant an ad-hoc patch release? Or what
> if the community has added functionality, that could "fill" a single minor
> release by itself, should that not warrant a pre-emptive release.
> >
> > All these questions are not enough to warrant this effort to be blocked,
> but I prefer those use cases to be considered for a more comprehensive
> documentation effort, than what is currently on the wiki.
> >
> > In addition to that, is a release with only bug fixes in it, really
> still a worthy of minor release number, or does it not count as a patch
> release?
> >
> > --Udo
> >
> >
> > On 10/8/18 14:27, 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 <am...@pivotal.io>
> >> 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!
> >>>
> >
>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Anthony Baker <ab...@pivotal.io>.
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 around what we are already doing / have been doing. Given that releases have significant overhead, I think it makes sense to plan ahead. If you want to know more about that ask Naba, the last release manager :-)
Anthony
> On Oct 8, 2018, at 2:42 PM, Udo Kohlmeyer <ud...@apache.org> wrote:
>
> -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 must agree with @Jacob, I would prefer something a lot less formalized. If the community has contributed a significant fix, should that not warrant an ad-hoc patch release? Or what if the community has added functionality, that could "fill" a single minor release by itself, should that not warrant a pre-emptive release.
>
> All these questions are not enough to warrant this effort to be blocked, but I prefer those use cases to be considered for a more comprehensive documentation effort, than what is currently on the wiki.
>
> In addition to that, is a release with only bug fixes in it, really still a worthy of minor release number, or does it not count as a patch release?
>
> --Udo
>
>
> On 10/8/18 14:27, 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 <am...@pivotal.io>
>> 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!
>>>
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Udo Kohlmeyer <ud...@apache.org>.
-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 must agree with @Jacob, I would prefer
something a lot less formalized. If the community has contributed a
significant fix, should that not warrant an ad-hoc patch release? Or
what if the community has added functionality, that could "fill" a
single minor release by itself, should that not warrant a pre-emptive
release.
All these questions are not enough to warrant this effort to be blocked,
but I prefer those use cases to be considered for a more comprehensive
documentation effort, than what is currently on the wiki.
In addition to that, is a release with only bug fixes in it, really
still a worthy of minor release number, or does it not count as a patch
release?
--Udo
On 10/8/18 14:27, 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 <am...@pivotal.io>
> 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!
>>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Nabarun Nag <nn...@pivotal.io>.
+1
On Mon, Oct 8, 2018 at 2:27 PM Jacob Barrett <jb...@pivotal.io> 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 <am...@pivotal.io>
> 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!
> >
>
Re: [VOTE] Time-based release schedule for minor releases
Posted by Jacob Barrett <jb...@pivotal.io>.
+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 <am...@pivotal.io>
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!
>