Re: [DISCUSS] Predictable minor release cadence

[Dan Smith]

>
> @Alexander, I don't believe that we can use the "DISCUSS" thread to have
> made a decision that we are going to do something.
>

We can and we should use DISCUSS threads to make decisions.

The only things that actually need votes are releases and new
committers/pmc members. Nothing else should need a vote unless we have a
very contentious issue where the will of the community is unclear, which
doesn't seem to be the case here.

See https://community.apache.org/committers/ and
https://community.apache.org/committers/decisionMaking.html

Re: [DISCUSS] Predictable minor release cadence

[Udo Kohlmeyer]

@Alexander, I don't believe that we can use the "DISCUSS" thread to have 
made a decision that we are going to do something.


Imo, it gauges interest rather than making a decision.

I would rather see the "VOTE" thread to be started, detailing the 
proposal and process how this will work. As I don't see how we can make 
decision on anything that isn't clearly defined. With clearly defined, I 
mean, what is the process regarding a major, minor and patch release. I 
agree with @Anthony, that all releases are treated equally... But as 
@Ken and @John have stated, what happens to the *patch* number? If it 
becomes a redundant, red-taped release, then we might end up with only 
*major*.*minor* releases.


--Udo


On 10/8/18 13:37, Alexander Murmann wrote:

Hi all,

Given the overwhelmingly positive response, I added a release schedule page
to the wiki:
https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule

Given the many "+1"s in this thread, can this be seen as agreed or do we
need a formal [VOTE] thread?

On Mon, Oct 8, 2018 at 1:34 PM Anthony Baker  wrote:


It’s an ASF requirement that PMC’s shepherd releases through a prescribed
set of practices.  It doesn’t matter if a release is major, minor, or
patch—they all must be voted and approved the the PMC.

Anthony



On Oct 8, 2018, at 1:04 PM, John Blum  wrote:

Also, a huge +1 to Ken's suggestion of actually using the

maintenance/patch

release version major.minor.*patch*, perhaps without all the "Apache
ceremony" around releasing.  Patches, should be quick and painless.

Re: [DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Hi all,

Given the overwhelmingly positive response, I added a release schedule page
to the wiki:
https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule

Given the many "+1"s in this thread, can this be seen as agreed or do we
need a formal [VOTE] thread?

On Mon, Oct 8, 2018 at 1:34 PM Anthony Baker  wrote:

> It’s an ASF requirement that PMC’s shepherd releases through a prescribed
> set of practices.  It doesn’t matter if a release is major, minor, or
> patch—they all must be voted and approved the the PMC.
>
> Anthony
>
>
> > On Oct 8, 2018, at 1:04 PM, John Blum  wrote:
> >
> > Also, a huge +1 to Ken's suggestion of actually using the
> maintenance/patch
> > release version major.minor.*patch*, perhaps without all the "Apache
> > ceremony" around releasing.  Patches, should be quick and painless.
>
>

Re: [DISCUSS] Predictable minor release cadence

[Anthony Baker]

It’s an ASF requirement that PMC’s shepherd releases through a prescribed set 
of practices.  It doesn’t matter if a release is major, minor, or patch—they 
all must be voted and approved the the PMC.

Anthony


> On Oct 8, 2018, at 1:04 PM, John Blum  wrote:
> 
> Also, a huge +1 to Ken's suggestion of actually using the maintenance/patch
> release version major.minor.*patch*, perhaps without all the "Apache
> ceremony" around releasing.  Patches, should be quick and painless.

Re: [DISCUSS] Predictable minor release cadence

[John Blum]

+1; a time-based approach also helps to keep scope in check (i.e. smaller
changes and change sets), which leads to faster feedback (either fail
faster, sooner or find out you are on the right track), and shows
users/customers active progress/forward momentum, which is only a good
thing.

Also, a huge +1 to Ken's suggestion of actually using the maintenance/patch
release version major.minor.*patch*, perhaps without all the "Apache
ceremony" around releasing.  Patches, should be quick and painless.

The over arching goal should always be... time to the realization of value
sooner, which can only be accomplished by more frequent releases, releasing
asap.  The "value" of a feature or improvement goes down after time.

$0.02
-John



On Mon, Oct 8, 2018 at 3:43 PM, Pulkit Chandra  wrote:

> +1,
>
> It's important to keep in mind, we are talking fixed time releases and not
> scoped releases. That means we have to be comfortable with the fact that
> some features wont make it in a release even though they might be just
> about to finish. Downstream products that use Geode need this
> predictability.
>
> *Pulkit Chandra*
>
> Product Team | Pivotal
>
> Cell: 201-509-1957 (Work)
>
> Location: New York City, NY
>
>
> On Fri, Oct 5, 2018 at 5:01 PM Michael Stolz  wrote:
>
> > +1 on cutting in Nov.
> > Seems like community could benefit from one more release this year.
> >
> > --
> > Mike Stolz
> > Principal Engineer - Gemfire Product Manager
> > Mobile: 631-835-4771
> >
> > On Oct 5, 2018 8:45 AM, "Anthony Baker"  wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  >
> > > wrote:
> > > >
> > > >> I have found it refreshing that the geode released cadence has been
> > > based
> > > >> on features being done,  rather than a set schedule.
> > > >>
> > > >> I come from an environment where we had quarterly releases and
> monthly
> > > >> patches to all supported previous releases, and I can tell you that
> it
> > > >> became a grind. That being said, within that release cadence a
> > one-month
> > > >> ramp for bug fixes on the release branch was almost always
> sufficient.
> > > >>
> > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > wrote:
> > > >>
> > > >>> +1 for scheduled releases and cutting the branch one month prior to
> > > >>> release. Given the time it took to fully root out, classify, and
> > solve
> > > >>> issues with this 1.7 release, I think a month is the right amount
> of
> > > time
> > > >>> between cutting the branch and releasing.  If it ends up being too
> > much
> > > >> or
> > > >>> too little, we can always adjust.
> > > >>>
> > > >>> I don’t feel strongly about the release cadence, but I generally
> > favor
> > > >> more
> > > >>> frequent releases if possible (3 month over 6 month).  That way new
> > > >>> features can get into the hands of users sooner, assuming the
> feature
> > > >> takes
> > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> if
> > > >>> necessary if it is too frequent or infrequent.
> > > >>>
> > > >>> Ryan
> > > >>>
> > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  Anil, releasing every 3 months should give us 3 months of dev
> work.
> > > >> Don't
> > >  forget that there will be one month during which the next release
> is
> > >  already cut, but the vast majority of the work is going to the
> > release
> > >  after that. So while we cut 1.7 one month ago and release 1.7
> today,
> > > we
> > >  already have one month of work on develop again. It's not going to
> > > work
> > > >>> out
> > >  for this first release though, due to my suggestion to cut a month
> > > >> early
> > > >>> to
> > >  avoid holidays. If I recall correctly our past problem was that it
> > > took
> > >  longer to iron out issue on the release branch than expected. The
> > > >>> solution
> > >  to that would be to cut the release even earlier, but 1 month
> feels
> > > >> very
> > >  generous.
> > > 
> > >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> > aging...@pivotal.io
> > > >
> > >  wrote:
> > > 
> > > 

Re: [DISCUSS] Predictable minor release cadence

[Pulkit Chandra]

+1,

It's important to keep in mind, we are talking fixed time releases and not
scoped releases. That means we have to be comfortable with the fact that
some features wont make it in a release even though they might be just
about to finish. Downstream products that use Geode need this
predictability.

*Pulkit Chandra*

Product Team | Pivotal

Cell: 201-509-1957 (Work)

Location: New York City, NY


On Fri, Oct 5, 2018 at 5:01 PM Michael Stolz  wrote:

> +1 on cutting in Nov.
> Seems like community could benefit from one more release this year.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Oct 5, 2018 8:45 AM, "Anthony Baker"  wrote:
>
> > I’ve been advocating for a fixed release schedule for a long time.  3
> > months seems like a good rate given the release overhead.
> >
> > +1 on cutting the next release branch in November and shooting for an
> > early December v1.8.0 release.
> >
> > Anthony
> >
> >
> > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda  >
> > wrote:
> > >
> > > I agree with Robert that we should release based on features that go
> in.
> > >
> > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > These tools were evolving rapidly in the last couple of years and
> > frequent
> > > releases would be good for a growing community.
> > >
> > > Should we do a patch release every few months to include bug fixes?
> > >
> > > Sai
> > >
> > >
> > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> > wrote:
> > >
> > >> I have found it refreshing that the geode released cadence has been
> > based
> > >> on features being done,  rather than a set schedule.
> > >>
> > >> I come from an environment where we had quarterly releases and monthly
> > >> patches to all supported previous releases, and I can tell you that it
> > >> became a grind. That being said, within that release cadence a
> one-month
> > >> ramp for bug fixes on the release branch was almost always sufficient.
> > >>
> > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> wrote:
> > >>
> > >>> +1 for scheduled releases and cutting the branch one month prior to
> > >>> release. Given the time it took to fully root out, classify, and
> solve
> > >>> issues with this 1.7 release, I think a month is the right amount of
> > time
> > >>> between cutting the branch and releasing.  If it ends up being too
> much
> > >> or
> > >>> too little, we can always adjust.
> > >>>
> > >>> I don’t feel strongly about the release cadence, but I generally
> favor
> > >> more
> > >>> frequent releases if possible (3 month over 6 month).  That way new
> > >>> features can get into the hands of users sooner, assuming the feature
> > >> takes
> > >>> less than 3 months to complete.  Again, we can adjust the cadence if
> > >>> necessary if it is too frequent or infrequent.
> > >>>
> > >>> Ryan
> > >>>
> > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> amurm...@pivotal.io>
> > >>> wrote:
> > >>>
> >  Anil, releasing every 3 months should give us 3 months of dev work.
> > >> Don't
> >  forget that there will be one month during which the next release is
> >  already cut, but the vast majority of the work is going to the
> release
> >  after that. So while we cut 1.7 one month ago and release 1.7 today,
> > we
> >  already have one month of work on develop again. It's not going to
> > work
> > >>> out
> >  for this first release though, due to my suggestion to cut a month
> > >> early
> > >>> to
> >  avoid holidays. If I recall correctly our past problem was that it
> > took
> >  longer to iron out issue on the release branch than expected. The
> > >>> solution
> >  to that would be to cut the release even earlier, but 1 month feels
> > >> very
> >  generous.
> > 
> >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> aging...@pivotal.io
> > >
> >  wrote:
> > 
> > > If I remember from earlier discussion; the plan was to deliver a
> > >>> release
> > > once 3 months. But from the past release history we had difficulty
> in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for
> > >> Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity
> that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides at least 3+ month
> > >> for
> >  dev
> > > activity and 1 month for QA.
> > >
> > > -Anil.
> > >
> > >
> > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith 
> wrote:
> > >
> > >> +1 I definitely like the idea of scheduled releases.
> > >>
> > >> I wonder if cutting the release branch a month ahead of time is
> >  overkill,
> > >> but I guess we do seem to keep finding issues after the branch is
> > >>> cut.
> > >>
> > >> -Dan
> > >>
> > >> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> > >>> 

Re: [DISCUSS] Predictable minor release cadence

[Michael Stolz]

+1 on cutting in Nov.
Seems like community could benefit from one more release this year.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Oct 5, 2018 8:45 AM, "Anthony Baker"  wrote:

> I’ve been advocating for a fixed release schedule for a long time.  3
> months seems like a good rate given the release overhead.
>
> +1 on cutting the next release branch in November and shooting for an
> early December v1.8.0 release.
>
> Anthony
>
>
> > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda 
> wrote:
> >
> > I agree with Robert that we should release based on features that go in.
> >
> > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > These tools were evolving rapidly in the last couple of years and
> frequent
> > releases would be good for a growing community.
> >
> > Should we do a patch release every few months to include bug fixes?
> >
> > Sai
> >
> >
> > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> wrote:
> >
> >> I have found it refreshing that the geode released cadence has been
> based
> >> on features being done,  rather than a set schedule.
> >>
> >> I come from an environment where we had quarterly releases and monthly
> >> patches to all supported previous releases, and I can tell you that it
> >> became a grind. That being said, within that release cadence a one-month
> >> ramp for bug fixes on the release branch was almost always sufficient.
> >>
> >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
> >>
> >>> +1 for scheduled releases and cutting the branch one month prior to
> >>> release. Given the time it took to fully root out, classify, and solve
> >>> issues with this 1.7 release, I think a month is the right amount of
> time
> >>> between cutting the branch and releasing.  If it ends up being too much
> >> or
> >>> too little, we can always adjust.
> >>>
> >>> I don’t feel strongly about the release cadence, but I generally favor
> >> more
> >>> frequent releases if possible (3 month over 6 month).  That way new
> >>> features can get into the hands of users sooner, assuming the feature
> >> takes
> >>> less than 3 months to complete.  Again, we can adjust the cadence if
> >>> necessary if it is too frequent or infrequent.
> >>>
> >>> Ryan
> >>>
> >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> >>> wrote:
> >>>
>  Anil, releasing every 3 months should give us 3 months of dev work.
> >> Don't
>  forget that there will be one month during which the next release is
>  already cut, but the vast majority of the work is going to the release
>  after that. So while we cut 1.7 one month ago and release 1.7 today,
> we
>  already have one month of work on develop again. It's not going to
> work
> >>> out
>  for this first release though, due to my suggestion to cut a month
> >> early
> >>> to
>  avoid holidays. If I recall correctly our past problem was that it
> took
>  longer to iron out issue on the release branch than expected. The
> >>> solution
>  to that would be to cut the release even earlier, but 1 month feels
> >> very
>  generous.
> 
>  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade  >
>  wrote:
> 
> > If I remember from earlier discussion; the plan was to deliver a
> >>> release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for
> >> Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month
> >> for
>  dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> >> +1 I definitely like the idea of scheduled releases.
> >>
> >> I wonder if cutting the release branch a month ahead of time is
>  overkill,
> >> but I guess we do seem to keep finding issues after the branch is
> >>> cut.
> >>
> >> -Dan
> >>
> >> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> >>> amurm...@pivotal.io>
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I want to propose shipping Geode on a regular cadence. My
> >> concrete
> >> proposal
> >>> is to ship Geode every 3 months on the first weekday. To make
> >> sure
> >>> we
> > hit
> >>> that date we would cut the release 1 months prior to that day.
> >>>
> >>> *Why?*
> >>> Knowing on what day the release will get cut and on what day we
> >>> ship
> >> allows
> >>> community members to plan their contributions. If I want my
> >> feature
>  to
> > be
> >>> in the next release I know by when I need to have it merged to
>  develop
> >> and
> >>> can plan accordingly. As a user who is waiting for a particular
>  

Re: [DISCUSS] Predictable minor release cadence

[Diane Hardman]

+1 to a regular cadence and starting with a 3-month cadence. As we learned
earlier this year, monthly was too frequent to support our testing cycles
and for users to update.

On Fri, Oct 5, 2018 at 11:54 AM, Robert Houghton 
wrote:

> +1 to Dan
>
> On Fri, Oct 5, 2018, 09:27 Dan Smith  wrote:
>
> > Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> > I'm fine with that plan, as long as we can stick to only putting critical
> > fixes on the release branch. Once the release branch is cut, it ships
> > without further changes unless we find new issues.
> >
> > -Dan
> >
> >
> > On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> > wrote:
> >
> > > Robert and Sai, I think either release process can be stressful if your
> > > team doesn't understand that there is no faster button, but that the
> only
> > > lever is to cut scope (you can also compromise quality, but let's not
> do
> > > that).
> > > In either scenario there can be release pressure. To me the biggest
> > > difference is that with a fixed schedule I at least have a good chance
> to
> > > see sooner that I need to cut scope to catch the next train. Without a
> > > fixed schedule, I suddenly might find myself in the situation that
> > everyone
> > > else is ready to ship and is waiting on me and getting impatient. I
> might
> > > have not even been able to see that coming unless I am constantly
> > checking
> > > with everyone else to find out when they think they might be ready to
> > ship.
> > >
> > > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> > have a
> > > massively growing community 
> > >
> > > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker 
> wrote:
> > >
> > > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > > months seems like a good rate given the release overhead.
> > > >
> > > > +1 on cutting the next release branch in November and shooting for an
> > > > early December v1.8.0 release.
> > > >
> > > > Anthony
> > > >
> > > >
> > > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> > sai.boorlaga...@gmail.com
> > > >
> > > > wrote:
> > > > >
> > > > > I agree with Robert that we should release based on features that
> go
> > > in.
> > > > >
> > > > > I am not sure if Apache Kafka & Spark are a good reference for
> GEODE.
> > > > > These tools were evolving rapidly in the last couple of years and
> > > > frequent
> > > > > releases would be good for a growing community.
> > > > >
> > > > > Should we do a patch release every few months to include bug fixes?
> > > > >
> > > > > Sai
> > > > >
> > > > >
> > > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton <
> rhough...@pivotal.io
> > >
> > > > wrote:
> > > > >
> > > > >> I have found it refreshing that the geode released cadence has
> been
> > > > based
> > > > >> on features being done,  rather than a set schedule.
> > > > >>
> > > > >> I come from an environment where we had quarterly releases and
> > monthly
> > > > >> patches to all supported previous releases, and I can tell you
> that
> > it
> > > > >> became a grind. That being said, within that release cadence a
> > > one-month
> > > > >> ramp for bug fixes on the release branch was almost always
> > sufficient.
> > > > >>
> > > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > > wrote:
> > > > >>
> > > > >>> +1 for scheduled releases and cutting the branch one month prior
> to
> > > > >>> release. Given the time it took to fully root out, classify, and
> > > solve
> > > > >>> issues with this 1.7 release, I think a month is the right amount
> > of
> > > > time
> > > > >>> between cutting the branch and releasing.  If it ends up being
> too
> > > much
> > > > >> or
> > > > >>> too little, we can always adjust.
> > > > >>>
> > > > >>> I don’t feel strongly about the release cadence, but I generally
> > > favor
> > > > >> more
> > > > >>> frequent releases if possible (3 month over 6 month).  That way
> new
> > > > >>> features can get into the hands of users sooner, assuming the
> > feature
> > > > >> takes
> > > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> > if
> > > > >>> necessary if it is too frequent or infrequent.
> > > > >>>
> > > > >>> Ryan
> > > > >>>
> > > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > > amurm...@pivotal.io>
> > > > >>> wrote:
> > > > >>>
> > > >  Anil, releasing every 3 months should give us 3 months of dev
> > work.
> > > > >> Don't
> > > >  forget that there will be one month during which the next
> release
> > is
> > > >  already cut, but the vast majority of the work is going to the
> > > release
> > > >  after that. So while we cut 1.7 one month ago and release 1.7
> > today,
> > > > we
> > > >  already have one month of work on develop again. It's not going
> to
> > > > work
> > > > >>> out
> > > >  for this first release though, due to my suggestion to cut a
> month
> > > > >> early
> > > > >>> to
> > > >  avoid holidays. If I recall correctly our 

Re: [DISCUSS] Predictable minor release cadence

[Robert Houghton]

+1 to Dan

On Fri, Oct 5, 2018, 09:27 Dan Smith  wrote:

> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
>
> -Dan
>
>
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
>
> > Robert and Sai, I think either release process can be stressful if your
> > team doesn't understand that there is no faster button, but that the only
> > lever is to cut scope (you can also compromise quality, but let's not do
> > that).
> > In either scenario there can be release pressure. To me the biggest
> > difference is that with a fixed schedule I at least have a good chance to
> > see sooner that I need to cut scope to catch the next train. Without a
> > fixed schedule, I suddenly might find myself in the situation that
> everyone
> > else is ready to ship and is waiting on me and getting impatient. I might
> > have not even been able to see that coming unless I am constantly
> checking
> > with everyone else to find out when they think they might be ready to
> ship.
> >
> > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> have a
> > massively growing community 
> >
> > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  >
> > > wrote:
> > > >
> > > >> I have found it refreshing that the geode released cadence has been
> > > based
> > > >> on features being done,  rather than a set schedule.
> > > >>
> > > >> I come from an environment where we had quarterly releases and
> monthly
> > > >> patches to all supported previous releases, and I can tell you that
> it
> > > >> became a grind. That being said, within that release cadence a
> > one-month
> > > >> ramp for bug fixes on the release branch was almost always
> sufficient.
> > > >>
> > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > wrote:
> > > >>
> > > >>> +1 for scheduled releases and cutting the branch one month prior to
> > > >>> release. Given the time it took to fully root out, classify, and
> > solve
> > > >>> issues with this 1.7 release, I think a month is the right amount
> of
> > > time
> > > >>> between cutting the branch and releasing.  If it ends up being too
> > much
> > > >> or
> > > >>> too little, we can always adjust.
> > > >>>
> > > >>> I don’t feel strongly about the release cadence, but I generally
> > favor
> > > >> more
> > > >>> frequent releases if possible (3 month over 6 month).  That way new
> > > >>> features can get into the hands of users sooner, assuming the
> feature
> > > >> takes
> > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> if
> > > >>> necessary if it is too frequent or infrequent.
> > > >>>
> > > >>> Ryan
> > > >>>
> > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  Anil, releasing every 3 months should give us 3 months of dev
> work.
> > > >> Don't
> > >  forget that there will be one month during which the next release
> is
> > >  already cut, but the vast majority of the work is going to the
> > release
> > >  after that. So while we cut 1.7 one month ago and release 1.7
> today,
> > > we
> > >  already have one month of work on develop again. It's not going to
> > > work
> > > >>> out
> > >  for this first release though, due to my suggestion to cut a month
> > > >> early
> > > >>> to
> > >  avoid holidays. If I recall correctly our past problem was that it
> > > took
> > >  longer to iron out issue on the release branch than expected. The
> > > >>> solution
> > >  to that would be to cut the release even earlier, but 1 month
> feels
> > > >> very
> > >  generous.
> > > 
> > >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> > aging...@pivotal.io
> > > >
> > >  wrote:
> > > 
> > > > If I remember from earlier discussion; the plan was to deliver a
> > > >>> release
> > > > once 3 months. But from the past release history we 

Re: [DISCUSS] Predictable minor release cadence

[Dave Barnes]

If we go with more frequent releases, the number of available releases will
ramp up quickly.
What would be the best policy regarding earlier releases?
The Geode website's Release page currently links to 1.7.0, 1.6.0, 1.5.0,
and 1.4.0.
Would it be prudent to adopt a policy (as suggested by Craig Russell,
secretary of ASF) of keeping the available-via-mirror list short by
archiving older releases?
Does this present any hardship to users of older versions? Does it
introduce additional time into the release process that must be accounted
for?
-Dave

On Fri, Oct 5, 2018 at 9:27 AM Dan Smith  wrote:

> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
>
> -Dan
>
>
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
>
> > Robert and Sai, I think either release process can be stressful if your
> > team doesn't understand that there is no faster button, but that the only
> > lever is to cut scope (you can also compromise quality, but let's not do
> > that).
> > In either scenario there can be release pressure. To me the biggest
> > difference is that with a fixed schedule I at least have a good chance to
> > see sooner that I need to cut scope to catch the next train. Without a
> > fixed schedule, I suddenly might find myself in the situation that
> everyone
> > else is ready to ship and is waiting on me and getting impatient. I might
> > have not even been able to see that coming unless I am constantly
> checking
> > with everyone else to find out when they think they might be ready to
> ship.
> >
> > To the Kafka & Spark point: I'd love to see Geode evolve rapidly and
> have a
> > massively growing community 
> >
> > On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
> >
> > > I’ve been advocating for a fixed release schedule for a long time.  3
> > > months seems like a good rate given the release overhead.
> > >
> > > +1 on cutting the next release branch in November and shooting for an
> > > early December v1.8.0 release.
> > >
> > > Anthony
> > >
> > >
> > > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda <
> sai.boorlaga...@gmail.com
> > >
> > > wrote:
> > > >
> > > > I agree with Robert that we should release based on features that go
> > in.
> > > >
> > > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > > These tools were evolving rapidly in the last couple of years and
> > > frequent
> > > > releases would be good for a growing community.
> > > >
> > > > Should we do a patch release every few months to include bug fixes?
> > > >
> > > > Sai
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  >
> > > wrote:
> > > >
> > > >> I have found it refreshing that the geode released cadence has been
> > > based
> > > >> on features being done,  rather than a set schedule.
> > > >>
> > > >> I come from an environment where we had quarterly releases and
> monthly
> > > >> patches to all supported previous releases, and I can tell you that
> it
> > > >> became a grind. That being said, within that release cadence a
> > one-month
> > > >> ramp for bug fixes on the release branch was almost always
> sufficient.
> > > >>
> > > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> > wrote:
> > > >>
> > > >>> +1 for scheduled releases and cutting the branch one month prior to
> > > >>> release. Given the time it took to fully root out, classify, and
> > solve
> > > >>> issues with this 1.7 release, I think a month is the right amount
> of
> > > time
> > > >>> between cutting the branch and releasing.  If it ends up being too
> > much
> > > >> or
> > > >>> too little, we can always adjust.
> > > >>>
> > > >>> I don’t feel strongly about the release cadence, but I generally
> > favor
> > > >> more
> > > >>> frequent releases if possible (3 month over 6 month).  That way new
> > > >>> features can get into the hands of users sooner, assuming the
> feature
> > > >> takes
> > > >>> less than 3 months to complete.  Again, we can adjust the cadence
> if
> > > >>> necessary if it is too frequent or infrequent.
> > > >>>
> > > >>> Ryan
> > > >>>
> > > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > >>> wrote:
> > > >>>
> > >  Anil, releasing every 3 months should give us 3 months of dev
> work.
> > > >> Don't
> > >  forget that there will be one month during which the next release
> is
> > >  already cut, but the vast majority of the work is going to the
> > release
> > >  after that. So while we cut 1.7 one month ago and release 1.7
> today,
> > > we
> > >  already have one month of work on develop again. It's not going to
> > > work
> > > >>> out
> > >  for this first release though, due to my suggestion to cut a month
> > > >> early
> > > >>> to
> > >  avoid holidays. If I recall correctly 

Re: [DISCUSS] Predictable minor release cadence

[Kenneth Howe]

+1 to releasing on a 3-month schedule and cutting the branch a month before the 
release.

I’ve always felt that releasing based on content tends to prolong the 
test/release cycle. Some features are held up from getting released due to 
waiting for other features to be completed. Releasing on a relatively short 
fixed cadence means that new work “gets out there” quicker. Even if a new 
feature doesn’t yet have all the bells and whistles implemented, the project 
can get feedback sooner on the usability of what is there.

> On Oct 5, 2018, at 9:27 AM, Dan Smith  wrote:
> 
> Ok, I buy your arguments to cut the release branch 1 month ahead of time.
> I'm fine with that plan, as long as we can stick to only putting critical
> fixes on the release branch. Once the release branch is cut, it ships
> without further changes unless we find new issues.
> 
> -Dan
> 
> 
> On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
> wrote:
> 
>> Robert and Sai, I think either release process can be stressful if your
>> team doesn't understand that there is no faster button, but that the only
>> lever is to cut scope (you can also compromise quality, but let's not do
>> that).
>> In either scenario there can be release pressure. To me the biggest
>> difference is that with a fixed schedule I at least have a good chance to
>> see sooner that I need to cut scope to catch the next train. Without a
>> fixed schedule, I suddenly might find myself in the situation that everyone
>> else is ready to ship and is waiting on me and getting impatient. I might
>> have not even been able to see that coming unless I am constantly checking
>> with everyone else to find out when they think they might be ready to ship.
>> 
>> To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
>> massively growing community 
>> 
>> On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
>> 
>>> I’ve been advocating for a fixed release schedule for a long time.  3
>>> months seems like a good rate given the release overhead.
>>> 
>>> +1 on cutting the next release branch in November and shooting for an
>>> early December v1.8.0 release.
>>> 
>>> Anthony
>>> 
>>> 
 On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda >> 
>>> wrote:
 
 I agree with Robert that we should release based on features that go
>> in.
 
 I am not sure if Apache Kafka & Spark are a good reference for GEODE.
 These tools were evolving rapidly in the last couple of years and
>>> frequent
 releases would be good for a growing community.
 
 Should we do a patch release every few months to include bug fixes?
 
 Sai
 
 
 On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
>>> wrote:
 
> I have found it refreshing that the geode released cadence has been
>>> based
> on features being done,  rather than a set schedule.
> 
> I come from an environment where we had quarterly releases and monthly
> patches to all supported previous releases, and I can tell you that it
> became a grind. That being said, within that release cadence a
>> one-month
> ramp for bug fixes on the release branch was almost always sufficient.
> 
> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
>> wrote:
> 
>> +1 for scheduled releases and cutting the branch one month prior to
>> release. Given the time it took to fully root out, classify, and
>> solve
>> issues with this 1.7 release, I think a month is the right amount of
>>> time
>> between cutting the branch and releasing.  If it ends up being too
>> much
> or
>> too little, we can always adjust.
>> 
>> I don’t feel strongly about the release cadence, but I generally
>> favor
> more
>> frequent releases if possible (3 month over 6 month).  That way new
>> features can get into the hands of users sooner, assuming the feature
> takes
>> less than 3 months to complete.  Again, we can adjust the cadence if
>> necessary if it is too frequent or infrequent.
>> 
>> Ryan
>> 
>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
>> amurm...@pivotal.io>
>> wrote:
>> 
>>> Anil, releasing every 3 months should give us 3 months of dev work.
> Don't
>>> forget that there will be one month during which the next release is
>>> already cut, but the vast majority of the work is going to the
>> release
>>> after that. So while we cut 1.7 one month ago and release 1.7 today,
>>> we
>>> already have one month of work on develop again. It's not going to
>>> work
>> out
>>> for this first release though, due to my suggestion to cut a month
> early
>> to
>>> avoid holidays. If I recall correctly our past problem was that it
>>> took
>>> longer to iron out issue on the release branch than expected. The
>> solution
>>> to that would be to cut the release even earlier, but 1 month feels
> very
>>> generous.
>>> 
>>> On Thu, Oct 4, 2018 at 4:04 PM 

Re: [DISCUSS] Predictable minor release cadence

[Dan Smith]

Ok, I buy your arguments to cut the release branch 1 month ahead of time.
I'm fine with that plan, as long as we can stick to only putting critical
fixes on the release branch. Once the release branch is cut, it ships
without further changes unless we find new issues.

-Dan


On Fri, Oct 5, 2018 at 8:58 AM Alexander Murmann 
wrote:

> Robert and Sai, I think either release process can be stressful if your
> team doesn't understand that there is no faster button, but that the only
> lever is to cut scope (you can also compromise quality, but let's not do
> that).
> In either scenario there can be release pressure. To me the biggest
> difference is that with a fixed schedule I at least have a good chance to
> see sooner that I need to cut scope to catch the next train. Without a
> fixed schedule, I suddenly might find myself in the situation that everyone
> else is ready to ship and is waiting on me and getting impatient. I might
> have not even been able to see that coming unless I am constantly checking
> with everyone else to find out when they think they might be ready to ship.
>
> To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
> massively growing community 
>
> On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:
>
> > I’ve been advocating for a fixed release schedule for a long time.  3
> > months seems like a good rate given the release overhead.
> >
> > +1 on cutting the next release branch in November and shooting for an
> > early December v1.8.0 release.
> >
> > Anthony
> >
> >
> > > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda  >
> > wrote:
> > >
> > > I agree with Robert that we should release based on features that go
> in.
> > >
> > > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > > These tools were evolving rapidly in the last couple of years and
> > frequent
> > > releases would be good for a growing community.
> > >
> > > Should we do a patch release every few months to include bug fixes?
> > >
> > > Sai
> > >
> > >
> > > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> > wrote:
> > >
> > >> I have found it refreshing that the geode released cadence has been
> > based
> > >> on features being done,  rather than a set schedule.
> > >>
> > >> I come from an environment where we had quarterly releases and monthly
> > >> patches to all supported previous releases, and I can tell you that it
> > >> became a grind. That being said, within that release cadence a
> one-month
> > >> ramp for bug fixes on the release branch was almost always sufficient.
> > >>
> > >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon 
> wrote:
> > >>
> > >>> +1 for scheduled releases and cutting the branch one month prior to
> > >>> release. Given the time it took to fully root out, classify, and
> solve
> > >>> issues with this 1.7 release, I think a month is the right amount of
> > time
> > >>> between cutting the branch and releasing.  If it ends up being too
> much
> > >> or
> > >>> too little, we can always adjust.
> > >>>
> > >>> I don’t feel strongly about the release cadence, but I generally
> favor
> > >> more
> > >>> frequent releases if possible (3 month over 6 month).  That way new
> > >>> features can get into the hands of users sooner, assuming the feature
> > >> takes
> > >>> less than 3 months to complete.  Again, we can adjust the cadence if
> > >>> necessary if it is too frequent or infrequent.
> > >>>
> > >>> Ryan
> > >>>
> > >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann <
> amurm...@pivotal.io>
> > >>> wrote:
> > >>>
> >  Anil, releasing every 3 months should give us 3 months of dev work.
> > >> Don't
> >  forget that there will be one month during which the next release is
> >  already cut, but the vast majority of the work is going to the
> release
> >  after that. So while we cut 1.7 one month ago and release 1.7 today,
> > we
> >  already have one month of work on develop again. It's not going to
> > work
> > >>> out
> >  for this first release though, due to my suggestion to cut a month
> > >> early
> > >>> to
> >  avoid holidays. If I recall correctly our past problem was that it
> > took
> >  longer to iron out issue on the release branch than expected. The
> > >>> solution
> >  to that would be to cut the release even earlier, but 1 month feels
> > >> very
> >  generous.
> > 
> >  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade <
> aging...@pivotal.io
> > >
> >  wrote:
> > 
> > > If I remember from earlier discussion; the plan was to deliver a
> > >>> release
> > > once 3 months. But from the past release history we had difficulty
> in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for
> > >> Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity
> that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides 

Re: [DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Robert and Sai, I think either release process can be stressful if your
team doesn't understand that there is no faster button, but that the only
lever is to cut scope (you can also compromise quality, but let's not do
that).
In either scenario there can be release pressure. To me the biggest
difference is that with a fixed schedule I at least have a good chance to
see sooner that I need to cut scope to catch the next train. Without a
fixed schedule, I suddenly might find myself in the situation that everyone
else is ready to ship and is waiting on me and getting impatient. I might
have not even been able to see that coming unless I am constantly checking
with everyone else to find out when they think they might be ready to ship.

To the Kafka & Spark point: I'd love to see Geode evolve rapidly and have a
massively growing community 

On Fri, Oct 5, 2018 at 8:45 AM Anthony Baker  wrote:

> I’ve been advocating for a fixed release schedule for a long time.  3
> months seems like a good rate given the release overhead.
>
> +1 on cutting the next release branch in November and shooting for an
> early December v1.8.0 release.
>
> Anthony
>
>
> > On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda 
> wrote:
> >
> > I agree with Robert that we should release based on features that go in.
> >
> > I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> > These tools were evolving rapidly in the last couple of years and
> frequent
> > releases would be good for a growing community.
> >
> > Should we do a patch release every few months to include bug fixes?
> >
> > Sai
> >
> >
> > On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton 
> wrote:
> >
> >> I have found it refreshing that the geode released cadence has been
> based
> >> on features being done,  rather than a set schedule.
> >>
> >> I come from an environment where we had quarterly releases and monthly
> >> patches to all supported previous releases, and I can tell you that it
> >> became a grind. That being said, within that release cadence a one-month
> >> ramp for bug fixes on the release branch was almost always sufficient.
> >>
> >> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
> >>
> >>> +1 for scheduled releases and cutting the branch one month prior to
> >>> release. Given the time it took to fully root out, classify, and solve
> >>> issues with this 1.7 release, I think a month is the right amount of
> time
> >>> between cutting the branch and releasing.  If it ends up being too much
> >> or
> >>> too little, we can always adjust.
> >>>
> >>> I don’t feel strongly about the release cadence, but I generally favor
> >> more
> >>> frequent releases if possible (3 month over 6 month).  That way new
> >>> features can get into the hands of users sooner, assuming the feature
> >> takes
> >>> less than 3 months to complete.  Again, we can adjust the cadence if
> >>> necessary if it is too frequent or infrequent.
> >>>
> >>> Ryan
> >>>
> >>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> >>> wrote:
> >>>
>  Anil, releasing every 3 months should give us 3 months of dev work.
> >> Don't
>  forget that there will be one month during which the next release is
>  already cut, but the vast majority of the work is going to the release
>  after that. So while we cut 1.7 one month ago and release 1.7 today,
> we
>  already have one month of work on develop again. It's not going to
> work
> >>> out
>  for this first release though, due to my suggestion to cut a month
> >> early
> >>> to
>  avoid holidays. If I recall correctly our past problem was that it
> took
>  longer to iron out issue on the release branch than expected. The
> >>> solution
>  to that would be to cut the release even earlier, but 1 month feels
> >> very
>  generous.
> 
>  On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade  >
>  wrote:
> 
> > If I remember from earlier discussion; the plan was to deliver a
> >>> release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for
> >> Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month
> >> for
>  dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> >> +1 I definitely like the idea of scheduled releases.
> >>
> >> I wonder if cutting the release branch a month ahead of time is
>  overkill,
> >> but I guess we do seem to keep finding issues after the branch is
> >>> cut.
> >>
> >> -Dan
> >>
> >> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> >>> amurm...@pivotal.io>
> >> wrote:
> >>
> >>> Hi everyone,
> >>>
> >>> I 

Re: [DISCUSS] Predictable minor release cadence

[Anthony Baker]

I’ve been advocating for a fixed release schedule for a long time.  3 months 
seems like a good rate given the release overhead.

+1 on cutting the next release branch in November and shooting for an early 
December v1.8.0 release.

Anthony


> On Oct 4, 2018, at 6:48 PM, Sai Boorlagadda  wrote:
> 
> I agree with Robert that we should release based on features that go in.
> 
> I am not sure if Apache Kafka & Spark are a good reference for GEODE.
> These tools were evolving rapidly in the last couple of years and frequent
> releases would be good for a growing community.
> 
> Should we do a patch release every few months to include bug fixes?
> 
> Sai
> 
> 
> On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  wrote:
> 
>> I have found it refreshing that the geode released cadence has been based
>> on features being done,  rather than a set schedule.
>> 
>> I come from an environment where we had quarterly releases and monthly
>> patches to all supported previous releases, and I can tell you that it
>> became a grind. That being said, within that release cadence a one-month
>> ramp for bug fixes on the release branch was almost always sufficient.
>> 
>> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
>> 
>>> +1 for scheduled releases and cutting the branch one month prior to
>>> release. Given the time it took to fully root out, classify, and solve
>>> issues with this 1.7 release, I think a month is the right amount of time
>>> between cutting the branch and releasing.  If it ends up being too much
>> or
>>> too little, we can always adjust.
>>> 
>>> I don’t feel strongly about the release cadence, but I generally favor
>> more
>>> frequent releases if possible (3 month over 6 month).  That way new
>>> features can get into the hands of users sooner, assuming the feature
>> takes
>>> less than 3 months to complete.  Again, we can adjust the cadence if
>>> necessary if it is too frequent or infrequent.
>>> 
>>> Ryan
>>> 
>>> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
>>> wrote:
>>> 
 Anil, releasing every 3 months should give us 3 months of dev work.
>> Don't
 forget that there will be one month during which the next release is
 already cut, but the vast majority of the work is going to the release
 after that. So while we cut 1.7 one month ago and release 1.7 today, we
 already have one month of work on develop again. It's not going to work
>>> out
 for this first release though, due to my suggestion to cut a month
>> early
>>> to
 avoid holidays. If I recall correctly our past problem was that it took
 longer to iron out issue on the release branch than expected. The
>>> solution
 to that would be to cut the release even earlier, but 1 month feels
>> very
 generous.
 
 On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
 wrote:
 
> If I remember from earlier discussion; the plan was to deliver a
>>> release
> once 3 months. But from the past release history we had difficulty in
> achieving that, either the features are not completely ready or the
> bug-fixes have taken more time. We need verify what is right for
>> Apache
> Geode, 3, 4 or 6 months; and there is any community dev/activity that
> depends on Geode release.
> My vote will be for 4 or 6 months, as it provides at least 3+ month
>> for
 dev
> activity and 1 month for QA.
> 
> -Anil.
> 
> 
> On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> 
>> +1 I definitely like the idea of scheduled releases.
>> 
>> I wonder if cutting the release branch a month ahead of time is
 overkill,
>> but I guess we do seem to keep finding issues after the branch is
>>> cut.
>> 
>> -Dan
>> 
>> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
>>> amurm...@pivotal.io>
>> wrote:
>> 
>>> Hi everyone,
>>> 
>>> I want to propose shipping Geode on a regular cadence. My
>> concrete
>> proposal
>>> is to ship Geode every 3 months on the first weekday. To make
>> sure
>>> we
> hit
>>> that date we would cut the release 1 months prior to that day.
>>> 
>>> *Why?*
>>> Knowing on what day the release will get cut and on what day we
>>> ship
>> allows
>>> community members to plan their contributions. If I want my
>> feature
 to
> be
>>> in the next release I know by when I need to have it merged to
 develop
>> and
>>> can plan accordingly. As a user who is waiting for a particular
 feature
>> or
>>> fix that's already on develop, I know when to expect the release
>>> that
>>> includes this work and again, can plan accordingly.
>>> 
>>> This makes working and using Apache Geode more predictable which
 makes
>> all
>>> our lives less stressful. To make this work, it's important to be
> strict
>>> about cutting the release branch on the set date and only allow
> critical
>>> fixes after the release 

Re: [DISCUSS] Predictable minor release cadence

[Sai Boorlagadda]

I agree with Robert that we should release based on features that go in.

I am not sure if Apache Kafka & Spark are a good reference for GEODE.
These tools were evolving rapidly in the last couple of years and frequent
releases would be good for a growing community.

Should we do a patch release every few months to include bug fixes?

Sai


On Thu, Oct 4, 2018 at 6:40 PM Robert Houghton  wrote:

> I have found it refreshing that the geode released cadence has been based
> on features being done,  rather than a set schedule.
>
> I come from an environment where we had quarterly releases and monthly
> patches to all supported previous releases, and I can tell you that it
> became a grind. That being said, within that release cadence a one-month
> ramp for bug fixes on the release branch was almost always sufficient.
>
> On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:
>
> > +1 for scheduled releases and cutting the branch one month prior to
> > release. Given the time it took to fully root out, classify, and solve
> > issues with this 1.7 release, I think a month is the right amount of time
> > between cutting the branch and releasing.  If it ends up being too much
> or
> > too little, we can always adjust.
> >
> > I don’t feel strongly about the release cadence, but I generally favor
> more
> > frequent releases if possible (3 month over 6 month).  That way new
> > features can get into the hands of users sooner, assuming the feature
> takes
> > less than 3 months to complete.  Again, we can adjust the cadence if
> > necessary if it is too frequent or infrequent.
> >
> > Ryan
> >
> > On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> > wrote:
> >
> > > Anil, releasing every 3 months should give us 3 months of dev work.
> Don't
> > > forget that there will be one month during which the next release is
> > > already cut, but the vast majority of the work is going to the release
> > > after that. So while we cut 1.7 one month ago and release 1.7 today, we
> > > already have one month of work on develop again. It's not going to work
> > out
> > > for this first release though, due to my suggestion to cut a month
> early
> > to
> > > avoid holidays. If I recall correctly our past problem was that it took
> > > longer to iron out issue on the release branch than expected. The
> > solution
> > > to that would be to cut the release even earlier, but 1 month feels
> very
> > > generous.
> > >
> > > On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> > > wrote:
> > >
> > > > If I remember from earlier discussion; the plan was to deliver a
> > release
> > > > once 3 months. But from the past release history we had difficulty in
> > > > achieving that, either the features are not completely ready or the
> > > > bug-fixes have taken more time. We need verify what is right for
> Apache
> > > > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > > > depends on Geode release.
> > > > My vote will be for 4 or 6 months, as it provides at least 3+ month
> for
> > > dev
> > > > activity and 1 month for QA.
> > > >
> > > > -Anil.
> > > >
> > > >
> > > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> > > >
> > > > > +1 I definitely like the idea of scheduled releases.
> > > > >
> > > > > I wonder if cutting the release branch a month ahead of time is
> > > overkill,
> > > > > but I guess we do seem to keep finding issues after the branch is
> > cut.
> > > > >
> > > > > -Dan
> > > > >
> > > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> > amurm...@pivotal.io>
> > > > > wrote:
> > > > >
> > > > > > Hi everyone,
> > > > > >
> > > > > > I want to propose shipping Geode on a regular cadence. My
> concrete
> > > > > proposal
> > > > > > is to ship Geode every 3 months on the first weekday. To make
> sure
> > we
> > > > hit
> > > > > > that date we would cut the release 1 months prior to that day.
> > > > > >
> > > > > > *Why?*
> > > > > > Knowing on what day the release will get cut and on what day we
> > ship
> > > > > allows
> > > > > > community members to plan their contributions. If I want my
> feature
> > > to
> > > > be
> > > > > > in the next release I know by when I need to have it merged to
> > > develop
> > > > > and
> > > > > > can plan accordingly. As a user who is waiting for a particular
> > > feature
> > > > > or
> > > > > > fix that's already on develop, I know when to expect the release
> > that
> > > > > > includes this work and again, can plan accordingly.
> > > > > >
> > > > > > This makes working and using Apache Geode more predictable which
> > > makes
> > > > > all
> > > > > > our lives less stressful. To make this work, it's important to be
> > > > strict
> > > > > > about cutting the release branch on the set date and only allow
> > > > critical
> > > > > > fixes after the release has been cut. Once we start compromising
> on
> > > > this,
> > > > > > we go down a slippery slope that ultimately leads to not getting
> > the
> > > > > > predictability benefits described 

Re: [DISCUSS] Predictable minor release cadence

[Robert Houghton]

I have found it refreshing that the geode released cadence has been based
on features being done,  rather than a set schedule.

I come from an environment where we had quarterly releases and monthly
patches to all supported previous releases, and I can tell you that it
became a grind. That being said, within that release cadence a one-month
ramp for bug fixes on the release branch was almost always sufficient.

On Thu, Oct 4, 2018, 18:32 Ryan McMahon  wrote:

> +1 for scheduled releases and cutting the branch one month prior to
> release. Given the time it took to fully root out, classify, and solve
> issues with this 1.7 release, I think a month is the right amount of time
> between cutting the branch and releasing.  If it ends up being too much or
> too little, we can always adjust.
>
> I don’t feel strongly about the release cadence, but I generally favor more
> frequent releases if possible (3 month over 6 month).  That way new
> features can get into the hands of users sooner, assuming the feature takes
> less than 3 months to complete.  Again, we can adjust the cadence if
> necessary if it is too frequent or infrequent.
>
> Ryan
>
> On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
> wrote:
>
> > Anil, releasing every 3 months should give us 3 months of dev work. Don't
> > forget that there will be one month during which the next release is
> > already cut, but the vast majority of the work is going to the release
> > after that. So while we cut 1.7 one month ago and release 1.7 today, we
> > already have one month of work on develop again. It's not going to work
> out
> > for this first release though, due to my suggestion to cut a month early
> to
> > avoid holidays. If I recall correctly our past problem was that it took
> > longer to iron out issue on the release branch than expected. The
> solution
> > to that would be to cut the release even earlier, but 1 month feels very
> > generous.
> >
> > On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> > wrote:
> >
> > > If I remember from earlier discussion; the plan was to deliver a
> release
> > > once 3 months. But from the past release history we had difficulty in
> > > achieving that, either the features are not completely ready or the
> > > bug-fixes have taken more time. We need verify what is right for Apache
> > > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > > depends on Geode release.
> > > My vote will be for 4 or 6 months, as it provides at least 3+ month for
> > dev
> > > activity and 1 month for QA.
> > >
> > > -Anil.
> > >
> > >
> > > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> > >
> > > > +1 I definitely like the idea of scheduled releases.
> > > >
> > > > I wonder if cutting the release branch a month ahead of time is
> > overkill,
> > > > but I guess we do seem to keep finding issues after the branch is
> cut.
> > > >
> > > > -Dan
> > > >
> > > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann <
> amurm...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Hi everyone,
> > > > >
> > > > > I want to propose shipping Geode on a regular cadence. My concrete
> > > > proposal
> > > > > is to ship Geode every 3 months on the first weekday. To make sure
> we
> > > hit
> > > > > that date we would cut the release 1 months prior to that day.
> > > > >
> > > > > *Why?*
> > > > > Knowing on what day the release will get cut and on what day we
> ship
> > > > allows
> > > > > community members to plan their contributions. If I want my feature
> > to
> > > be
> > > > > in the next release I know by when I need to have it merged to
> > develop
> > > > and
> > > > > can plan accordingly. As a user who is waiting for a particular
> > feature
> > > > or
> > > > > fix that's already on develop, I know when to expect the release
> that
> > > > > includes this work and again, can plan accordingly.
> > > > >
> > > > > This makes working and using Apache Geode more predictable which
> > makes
> > > > all
> > > > > our lives less stressful. To make this work, it's important to be
> > > strict
> > > > > about cutting the release branch on the set date and only allow
> > > critical
> > > > > fixes after the release has been cut. Once we start compromising on
> > > this,
> > > > > we go down a slippery slope that ultimately leads to not getting
> the
> > > > > predictability benefits described here.
> > > > >
> > > > > Some other successful Apache projects share similar approaches:
> > > > >
> > > > >- Kafka
> > > > ><
> > > >
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > > > >releases every 4 months and cuts the release 1 month prior
> > > > >- PredictionIO <
> > https://predictionio.apache.org/resources/release/>
> > > > > releases
> > > > >every 2 months
> > > > >- Spark  does
> > not
> > > > seem
> > > > >to have a hard date, but aims to ship every 6 months, so there
> is
> > at
> > > > > least
> > > > >a goal 

Re: [DISCUSS] Predictable minor release cadence

[Ryan McMahon]

+1 for scheduled releases and cutting the branch one month prior to
release. Given the time it took to fully root out, classify, and solve
issues with this 1.7 release, I think a month is the right amount of time
between cutting the branch and releasing.  If it ends up being too much or
too little, we can always adjust.

I don’t feel strongly about the release cadence, but I generally favor more
frequent releases if possible (3 month over 6 month).  That way new
features can get into the hands of users sooner, assuming the feature takes
less than 3 months to complete.  Again, we can adjust the cadence if
necessary if it is too frequent or infrequent.

Ryan

On Thu, Oct 4, 2018 at 4:18 PM Alexander Murmann 
wrote:

> Anil, releasing every 3 months should give us 3 months of dev work. Don't
> forget that there will be one month during which the next release is
> already cut, but the vast majority of the work is going to the release
> after that. So while we cut 1.7 one month ago and release 1.7 today, we
> already have one month of work on develop again. It's not going to work out
> for this first release though, due to my suggestion to cut a month early to
> avoid holidays. If I recall correctly our past problem was that it took
> longer to iron out issue on the release branch than expected. The solution
> to that would be to cut the release even earlier, but 1 month feels very
> generous.
>
> On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
> wrote:
>
> > If I remember from earlier discussion; the plan was to deliver a release
> > once 3 months. But from the past release history we had difficulty in
> > achieving that, either the features are not completely ready or the
> > bug-fixes have taken more time. We need verify what is right for Apache
> > Geode, 3, 4 or 6 months; and there is any community dev/activity that
> > depends on Geode release.
> > My vote will be for 4 or 6 months, as it provides at least 3+ month for
> dev
> > activity and 1 month for QA.
> >
> > -Anil.
> >
> >
> > On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
> >
> > > +1 I definitely like the idea of scheduled releases.
> > >
> > > I wonder if cutting the release branch a month ahead of time is
> overkill,
> > > but I guess we do seem to keep finding issues after the branch is cut.
> > >
> > > -Dan
> > >
> > > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I want to propose shipping Geode on a regular cadence. My concrete
> > > proposal
> > > > is to ship Geode every 3 months on the first weekday. To make sure we
> > hit
> > > > that date we would cut the release 1 months prior to that day.
> > > >
> > > > *Why?*
> > > > Knowing on what day the release will get cut and on what day we ship
> > > allows
> > > > community members to plan their contributions. If I want my feature
> to
> > be
> > > > in the next release I know by when I need to have it merged to
> develop
> > > and
> > > > can plan accordingly. As a user who is waiting for a particular
> feature
> > > or
> > > > fix that's already on develop, I know when to expect the release that
> > > > includes this work and again, can plan accordingly.
> > > >
> > > > This makes working and using Apache Geode more predictable which
> makes
> > > all
> > > > our lives less stressful. To make this work, it's important to be
> > strict
> > > > about cutting the release branch on the set date and only allow
> > critical
> > > > fixes after the release has been cut. Once we start compromising on
> > this,
> > > > we go down a slippery slope that ultimately leads to not getting the
> > > > predictability benefits described here.
> > > >
> > > > Some other successful Apache projects share similar approaches:
> > > >
> > > >- Kafka
> > > ><
> > > https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > > >releases every 4 months and cuts the release 1 month prior
> > > >- PredictionIO <
> https://predictionio.apache.org/resources/release/>
> > > > releases
> > > >every 2 months
> > > >- Spark  does
> not
> > > seem
> > > >to have a hard date, but aims to ship every 6 months, so there is
> at
> > > > least
> > > >a goal date
> > > >
> > > >
> > > > *What?*
> > > > As stated above, I suggest to release every three months. Given we
> just
> > > > shipped the next release would go out on January 2nd. That timing in
> > > > unfortunate, due to the holidays. Therefore I propose to aim for a
> > > December
> > > > 3rd (1st Monday in December) release. In order to meet that date, we
> > > should
> > > > cut the release branch on November 1st. That also means that we
> should
> > > > start finding a volunteer to manager the release on October 25th. I
> > know
> > > > this seems really close, given we just shipped, but keep in mind that
> > > this
> > > > is to avoid the holidays and that we already have close to a month
> > worth
> > > of
> 

Re: [DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Anil, releasing every 3 months should give us 3 months of dev work. Don't
forget that there will be one month during which the next release is
already cut, but the vast majority of the work is going to the release
after that. So while we cut 1.7 one month ago and release 1.7 today, we
already have one month of work on develop again. It's not going to work out
for this first release though, due to my suggestion to cut a month early to
avoid holidays. If I recall correctly our past problem was that it took
longer to iron out issue on the release branch than expected. The solution
to that would be to cut the release even earlier, but 1 month feels very
generous.

On Thu, Oct 4, 2018 at 4:04 PM Anilkumar Gingade 
wrote:

> If I remember from earlier discussion; the plan was to deliver a release
> once 3 months. But from the past release history we had difficulty in
> achieving that, either the features are not completely ready or the
> bug-fixes have taken more time. We need verify what is right for Apache
> Geode, 3, 4 or 6 months; and there is any community dev/activity that
> depends on Geode release.
> My vote will be for 4 or 6 months, as it provides at least 3+ month for dev
> activity and 1 month for QA.
>
> -Anil.
>
>
> On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:
>
> > +1 I definitely like the idea of scheduled releases.
> >
> > I wonder if cutting the release branch a month ahead of time is overkill,
> > but I guess we do seem to keep finding issues after the branch is cut.
> >
> > -Dan
> >
> > On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I want to propose shipping Geode on a regular cadence. My concrete
> > proposal
> > > is to ship Geode every 3 months on the first weekday. To make sure we
> hit
> > > that date we would cut the release 1 months prior to that day.
> > >
> > > *Why?*
> > > Knowing on what day the release will get cut and on what day we ship
> > allows
> > > community members to plan their contributions. If I want my feature to
> be
> > > in the next release I know by when I need to have it merged to develop
> > and
> > > can plan accordingly. As a user who is waiting for a particular feature
> > or
> > > fix that's already on develop, I know when to expect the release that
> > > includes this work and again, can plan accordingly.
> > >
> > > This makes working and using Apache Geode more predictable which makes
> > all
> > > our lives less stressful. To make this work, it's important to be
> strict
> > > about cutting the release branch on the set date and only allow
> critical
> > > fixes after the release has been cut. Once we start compromising on
> this,
> > > we go down a slippery slope that ultimately leads to not getting the
> > > predictability benefits described here.
> > >
> > > Some other successful Apache projects share similar approaches:
> > >
> > >- Kafka
> > ><
> > https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> > >releases every 4 months and cuts the release 1 month prior
> > >- PredictionIO 
> > > releases
> > >every 2 months
> > >- Spark  does not
> > seem
> > >to have a hard date, but aims to ship every 6 months, so there is at
> > > least
> > >a goal date
> > >
> > >
> > > *What?*
> > > As stated above, I suggest to release every three months. Given we just
> > > shipped the next release would go out on January 2nd. That timing in
> > > unfortunate, due to the holidays. Therefore I propose to aim for a
> > December
> > > 3rd (1st Monday in December) release. In order to meet that date, we
> > should
> > > cut the release branch on November 1st. That also means that we should
> > > start finding a volunteer to manager the release on October 25th. I
> know
> > > this seems really close, given we just shipped, but keep in mind that
> > this
> > > is to avoid the holidays and that we already have close to a month
> worth
> > of
> > > work on develop.
> > >
> > > *Proposed near future schedule:*
> > > October 25th: Find release manager
> > > November 1st: Cut 1.8 release branch
> > > December 1st: Ship 1.8
> > > January 28th: Find release manager
> > > February 1st: Cut 1.9 release branch
> > > March 1st: Ship 1.9
> > > and so on...
> > >
> > > Thanks for sharing your thoughts and feedback on this!
> > >
> >
>

Re: [DISCUSS] Predictable minor release cadence

[Anilkumar Gingade]

If I remember from earlier discussion; the plan was to deliver a release
once 3 months. But from the past release history we had difficulty in
achieving that, either the features are not completely ready or the
bug-fixes have taken more time. We need verify what is right for Apache
Geode, 3, 4 or 6 months; and there is any community dev/activity that
depends on Geode release.
My vote will be for 4 or 6 months, as it provides at least 3+ month for dev
activity and 1 month for QA.

-Anil.


On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:

> +1 I definitely like the idea of scheduled releases.
>
> I wonder if cutting the release branch a month ahead of time is overkill,
> but I guess we do seem to keep finding issues after the branch is cut.
>
> -Dan
>
> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> wrote:
>
> > Hi everyone,
> >
> > I want to propose shipping Geode on a regular cadence. My concrete
> proposal
> > is to ship Geode every 3 months on the first weekday. To make sure we hit
> > that date we would cut the release 1 months prior to that day.
> >
> > *Why?*
> > Knowing on what day the release will get cut and on what day we ship
> allows
> > community members to plan their contributions. If I want my feature to be
> > in the next release I know by when I need to have it merged to develop
> and
> > can plan accordingly. As a user who is waiting for a particular feature
> or
> > fix that's already on develop, I know when to expect the release that
> > includes this work and again, can plan accordingly.
> >
> > This makes working and using Apache Geode more predictable which makes
> all
> > our lives less stressful. To make this work, it's important to be strict
> > about cutting the release branch on the set date and only allow critical
> > fixes after the release has been cut. Once we start compromising on this,
> > we go down a slippery slope that ultimately leads to not getting the
> > predictability benefits described here.
> >
> > Some other successful Apache projects share similar approaches:
> >
> >- Kafka
> ><
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> >releases every 4 months and cuts the release 1 month prior
> >- PredictionIO 
> > releases
> >every 2 months
> >- Spark  does not
> seem
> >to have a hard date, but aims to ship every 6 months, so there is at
> > least
> >a goal date
> >
> >
> > *What?*
> > As stated above, I suggest to release every three months. Given we just
> > shipped the next release would go out on January 2nd. That timing in
> > unfortunate, due to the holidays. Therefore I propose to aim for a
> December
> > 3rd (1st Monday in December) release. In order to meet that date, we
> should
> > cut the release branch on November 1st. That also means that we should
> > start finding a volunteer to manager the release on October 25th. I know
> > this seems really close, given we just shipped, but keep in mind that
> this
> > is to avoid the holidays and that we already have close to a month worth
> of
> > work on develop.
> >
> > *Proposed near future schedule:*
> > October 25th: Find release manager
> > November 1st: Cut 1.8 release branch
> > December 1st: Ship 1.8
> > January 28th: Find release manager
> > February 1st: Cut 1.9 release branch
> > March 1st: Ship 1.9
> > and so on...
> >
> > Thanks for sharing your thoughts and feedback on this!
> >
>

Re: [DISCUSS] Predictable minor release cadence

[Nabarun Nag]

+1 on the scheduled release and also on one month prior to release we cut
the branch.

@Dan  I feel keeping a one month will give a very comfortable time frame to
test + retest the release branch and we will be releasing a stable release
candidate.
For 1.7.0, it did take a month from cutting the branch till releasing RC2.
As testing of release/1.7.0 + RC1 was time bounded as voting time frame was
72hours. If we have the release branch for a month, we don't have to hurry
with the testing.

Regards
Nabarun Nag

On Thu, Oct 4, 2018 at 2:43 PM Dan Smith  wrote:

> +1 I definitely like the idea of scheduled releases.
>
> I wonder if cutting the release branch a month ahead of time is overkill,
> but I guess we do seem to keep finding issues after the branch is cut.
>
> -Dan
>
> On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
> wrote:
>
> > Hi everyone,
> >
> > I want to propose shipping Geode on a regular cadence. My concrete
> proposal
> > is to ship Geode every 3 months on the first weekday. To make sure we hit
> > that date we would cut the release 1 months prior to that day.
> >
> > *Why?*
> > Knowing on what day the release will get cut and on what day we ship
> allows
> > community members to plan their contributions. If I want my feature to be
> > in the next release I know by when I need to have it merged to develop
> and
> > can plan accordingly. As a user who is waiting for a particular feature
> or
> > fix that's already on develop, I know when to expect the release that
> > includes this work and again, can plan accordingly.
> >
> > This makes working and using Apache Geode more predictable which makes
> all
> > our lives less stressful. To make this work, it's important to be strict
> > about cutting the release branch on the set date and only allow critical
> > fixes after the release has been cut. Once we start compromising on this,
> > we go down a slippery slope that ultimately leads to not getting the
> > predictability benefits described here.
> >
> > Some other successful Apache projects share similar approaches:
> >
> >- Kafka
> ><
> https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan>
> >releases every 4 months and cuts the release 1 month prior
> >- PredictionIO 
> > releases
> >every 2 months
> >- Spark  does not
> seem
> >to have a hard date, but aims to ship every 6 months, so there is at
> > least
> >a goal date
> >
> >
> > *What?*
> > As stated above, I suggest to release every three months. Given we just
> > shipped the next release would go out on January 2nd. That timing in
> > unfortunate, due to the holidays. Therefore I propose to aim for a
> December
> > 3rd (1st Monday in December) release. In order to meet that date, we
> should
> > cut the release branch on November 1st. That also means that we should
> > start finding a volunteer to manager the release on October 25th. I know
> > this seems really close, given we just shipped, but keep in mind that
> this
> > is to avoid the holidays and that we already have close to a month worth
> of
> > work on develop.
> >
> > *Proposed near future schedule:*
> > October 25th: Find release manager
> > November 1st: Cut 1.8 release branch
> > December 1st: Ship 1.8
> > January 28th: Find release manager
> > February 1st: Cut 1.9 release branch
> > March 1st: Ship 1.9
> > and so on...
> >
> > Thanks for sharing your thoughts and feedback on this!
> >
>

Re: [DISCUSS] Predictable minor release cadence

[Dan Smith]

+1 I definitely like the idea of scheduled releases.

I wonder if cutting the release branch a month ahead of time is overkill,
but I guess we do seem to keep finding issues after the branch is cut.

-Dan

On Thu, Oct 4, 2018 at 1:25 PM Alexander Murmann 
wrote:

> Hi everyone,
>
> I want to propose shipping Geode on a regular cadence. My concrete proposal
> is to ship Geode every 3 months on the first weekday. To make sure we hit
> that date we would cut the release 1 months prior to that day.
>
> *Why?*
> Knowing on what day the release will get cut and on what day we ship allows
> community members to plan their contributions. If I want my feature to be
> in the next release I know by when I need to have it merged to develop and
> can plan accordingly. As a user who is waiting for a particular feature or
> fix that's already on develop, I know when to expect the release that
> includes this work and again, can plan accordingly.
>
> This makes working and using Apache Geode more predictable which makes all
> our lives less stressful. To make this work, it's important to be strict
> about cutting the release branch on the set date and only allow critical
> fixes after the release has been cut. Once we start compromising on this,
> we go down a slippery slope that ultimately leads to not getting the
> predictability benefits described here.
>
> Some other successful Apache projects share similar approaches:
>
>- Kafka
>
>releases every 4 months and cuts the release 1 month prior
>- PredictionIO 
> releases
>every 2 months
>- Spark  does not seem
>to have a hard date, but aims to ship every 6 months, so there is at
> least
>a goal date
>
>
> *What?*
> As stated above, I suggest to release every three months. Given we just
> shipped the next release would go out on January 2nd. That timing in
> unfortunate, due to the holidays. Therefore I propose to aim for a December
> 3rd (1st Monday in December) release. In order to meet that date, we should
> cut the release branch on November 1st. That also means that we should
> start finding a volunteer to manager the release on October 25th. I know
> this seems really close, given we just shipped, but keep in mind that this
> is to avoid the holidays and that we already have close to a month worth of
> work on develop.
>
> *Proposed near future schedule:*
> October 25th: Find release manager
> November 1st: Cut 1.8 release branch
> December 1st: Ship 1.8
> January 28th: Find release manager
> February 1st: Cut 1.9 release branch
> March 1st: Ship 1.9
> and so on...
>
> Thanks for sharing your thoughts and feedback on this!
>

[DISCUSS] Predictable minor release cadence

[Alexander Murmann]

Hi everyone,

I want to propose shipping Geode on a regular cadence. My concrete proposal
is to ship Geode every 3 months on the first weekday. To make sure we hit
that date we would cut the release 1 months prior to that day.

*Why?*
Knowing on what day the release will get cut and on what day we ship allows
community members to plan their contributions. If I want my feature to be
in the next release I know by when I need to have it merged to develop and
can plan accordingly. As a user who is waiting for a particular feature or
fix that's already on develop, I know when to expect the release that
includes this work and again, can plan accordingly.

This makes working and using Apache Geode more predictable which makes all
our lives less stressful. To make this work, it's important to be strict
about cutting the release branch on the set date and only allow critical
fixes after the release has been cut. Once we start compromising on this,
we go down a slippery slope that ultimately leads to not getting the
predictability benefits described here.

Some other successful Apache projects share similar approaches:

   - Kafka
   
   releases every 4 months and cuts the release 1 month prior
   - PredictionIO  releases
   every 2 months
   - Spark  does not seem
   to have a hard date, but aims to ship every 6 months, so there is at least
   a goal date


*What?*
As stated above, I suggest to release every three months. Given we just
shipped the next release would go out on January 2nd. That timing in
unfortunate, due to the holidays. Therefore I propose to aim for a December
3rd (1st Monday in December) release. In order to meet that date, we should
cut the release branch on November 1st. That also means that we should
start finding a volunteer to manager the release on October 25th. I know
this seems really close, given we just shipped, but keep in mind that this
is to avoid the holidays and that we already have close to a month worth of
work on develop.

*Proposed near future schedule:*
October 25th: Find release manager
November 1st: Cut 1.8 release branch
December 1st: Ship 1.8
January 28th: Find release manager
February 1st: Cut 1.9 release branch
March 1st: Ship 1.9
and so on...

Thanks for sharing your thoughts and feedback on this!