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/04 20:15:51 UTC
[DISCUSS] Predictable minor release cadence
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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Nabarun Nag <nn...@apache.org>.
+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 <ds...@pivotal.io> 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 <am...@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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Kenneth Howe <kh...@pivotal.io>.
+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 <ds...@pivotal.io> 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 <am...@pivotal.io>
> 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 <ab...@pivotal.io> 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.boorlagadda@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 <rh...@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 <mc...@apache.org>
>> 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 <
>> amurmann@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 <
>> agingade@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 <ds...@pivotal.io>
>> 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 <
>>>>>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
>>>>> 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
Posted by Diane Hardman <dh...@pivotal.io>.
+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 <rh...@pivotal.io>
wrote:
> +1 to Dan
>
> On Fri, Oct 5, 2018, 09:27 Dan Smith <ds...@pivotal.io> 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 <am...@pivotal.io>
> > 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 <ab...@pivotal.io>
> 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.boorlagadda@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 <
> rhoughton@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 <mc...@apache.org>
> > > 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 <
> > > amurmann@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 <
> > > agingade@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 <ds...@pivotal.io>
> > > 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 <
> > > > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > > > >> 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
Posted by Robert Houghton <rh...@pivotal.io>.
+1 to Dan
On Fri, Oct 5, 2018, 09:27 Dan Smith <ds...@pivotal.io> 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 <am...@pivotal.io>
> 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 <ab...@pivotal.io> 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.boorlagadda@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 <rhoughton@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 <mc...@apache.org>
> > 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 <
> > amurmann@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 <
> > agingade@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 <ds...@pivotal.io>
> > 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 <
> > > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > > >> 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
Posted by Dave Barnes <db...@pivotal.io>.
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 <ds...@pivotal.io> 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 <am...@pivotal.io>
> 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 <ab...@pivotal.io> 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.boorlagadda@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 <rhoughton@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 <mc...@apache.org>
> > 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 <
> > amurmann@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 <
> > agingade@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 <ds...@pivotal.io>
> > 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 <
> > > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > > >> 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
Posted by Dan Smith <ds...@pivotal.io>.
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 <am...@pivotal.io>
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 <ab...@pivotal.io> 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.boorlagadda@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 <rh...@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 <mc...@apache.org>
> 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 <
> amurmann@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 <
> agingade@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 <ds...@pivotal.io>
> 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 <
> > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > >> 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
Posted by Alexander Murmann <am...@pivotal.io>.
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 <ab...@pivotal.io> 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 <sa...@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 <rh...@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 <mc...@apache.org> 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 <am...@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 <agingade@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 <ds...@pivotal.io> 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 <
> >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> >> 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
Posted by Dan Smith <ds...@pivotal.io>.
>
> @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
Posted by Udo Kohlmeyer <ud...@apache.org>.
@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 <ab...@pivotal.io> 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 <jb...@pivotal.io> 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
Posted by Alexander Murmann <am...@pivotal.io>.
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 <ab...@pivotal.io> 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 <jb...@pivotal.io> 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
Posted by Anthony Baker <ab...@pivotal.io>.
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 <jb...@pivotal.io> 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
Posted by John Blum <jb...@pivotal.io>.
+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 <pc...@pivotal.io> 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 <ms...@pivotal.io> 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" <ab...@pivotal.io> 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.boorlagadda@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 <rhoughton@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 <mc...@apache.org>
> > 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 <
> > amurmann@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 <
> > agingade@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 <ds...@pivotal.io>
> > 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 <
> > > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > > >> 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!
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
>
--
-John
john.blum10101 (skype)
Re: [DISCUSS] Predictable minor release cadence
Posted by Pulkit Chandra <pc...@pivotal.io>.
+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 <ms...@pivotal.io> 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" <ab...@pivotal.io> 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.boorlagadda@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 <rh...@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 <mc...@apache.org>
> 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 <
> amurmann@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 <
> agingade@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 <ds...@pivotal.io>
> 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 <
> > >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> > >> 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
Posted by Michael Stolz <ms...@pivotal.io>.
+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" <ab...@pivotal.io> 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 <sa...@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 <rh...@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 <mc...@apache.org> 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 <am...@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 <agingade@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 <ds...@pivotal.io> 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 <
> >>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
> >> 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
Posted by Anthony Baker <ab...@pivotal.io>.
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 <sa...@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 <rh...@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 <mc...@apache.org> 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 <am...@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 <ag...@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 <ds...@pivotal.io> 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 <
>>> amurmann@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 <https://spark.apache.org/versioning-policy.html>
>> 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
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <rh...@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 <mc...@apache.org> 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 <am...@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 <ag...@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 <ds...@pivotal.io> 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 <
> > amurmann@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 <https://spark.apache.org/versioning-policy.html>
> 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
Posted by Robert Houghton <rh...@pivotal.io>.
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 <mc...@apache.org> 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 <am...@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 <ag...@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 <ds...@pivotal.io> 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 <
> amurmann@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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Ryan McMahon <mc...@apache.org>.
+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 <am...@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 <ag...@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 <ds...@pivotal.io> 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 <am...@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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Alexander Murmann <am...@pivotal.io>.
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 <ag...@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 <ds...@pivotal.io> 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 <am...@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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <ds...@pivotal.io> 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 <am...@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 <https://spark.apache.org/versioning-policy.html> 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
Posted by Dan Smith <ds...@pivotal.io>.
+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 <am...@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 <https://spark.apache.org/versioning-policy.html> 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!
>