Re: Release policy and 1.6 release schedule

[Greg Mann <gr...@mesosphere.io>]

Hey folks,
I've posted a proposed update to our documented release schedule:
https://reviews.apache.org/r/66454/

Please take a look and comment!

Cheers,
Greg


On Mon, Mar 26, 2018 at 11:34 AM, Greg Mann <gr...@mesosphere.io> wrote:

> +1 for quarterly. I would also say that we should support 3 releases at
> any given time, regardless of the duration that implies. If there are no
> objections, I'll submit a patch to update our docs to this effect. I think
> that slowing down our documented cadence a bit will give us a chance to
> faithfully adhere to our stated policy.
>
> Alex, I agree that releasing monthly would be great if we had better
> automation. This is something we can work toward in the future I hope :)
>
> Cheers,
> Greg
>
> On Mon, Mar 26, 2018 at 6:49 AM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
>
>> I would like us to do monthly releases and support 10 branches at a time.
>> Ideally, releasing that often reduces the burden for the release manager,
>> because there are less changes and less new features. However, we lack
>> automation to support this pace: our release guide [1] is several pages
>> long and includes quite a few non-trivial steps. It would be great to find
>> some time (maybe during the next Mesos hackathon?) and revisit our release
>> procedures, but until then I'm +1 for quarterly.
>>
>> [1] https://mesos.apache.org/documentation/latest/release-guide/
>>
>> On Sat, Mar 24, 2018 at 5:48 AM, Vinod Kone <vi...@gmail.com> wrote:
>>
>> > I’m +1 for quarterly.
>> >
>> > Most importantly I want us to adhere to a predictable cadence.
>> >
>> > Sent from my phone
>> >
>> > On Mar 23, 2018, at 9:21 PM, Jie Yu <yu...@gmail.com> wrote:
>> >
>> > It's a burden for supporting multiple releases.
>> >
>> > 1.2 was released March, 2017 (1 year ago), and I know that some users
>> are
>> > still on that version
>> > 1.3 was released June, 2017 (9 months ago), and we're still maintaining
>> it
>> > (still backport patches
>> > <https://github.com/apache/mesos/commit/064f64552624e38d5dd9
>> 2660eef6f6940128c106> several
>> > days ago, which some users asked)
>> > 1.4 was released Sept, 2017 (6 months ago).
>> > 1.5 was released Feb, 2018 (1 month ago).
>> >
>> > As you can see, users expect a release to be supported 6-9 months (e.g.,
>> > backports are still needed for 1.3 release, which is 9 months old). If
>> we
>> > were to do monthly minor release, we'll probably need to maintain 6-9
>> > release branches? That's too much of an ask for committers and
>> maintainers.
>> >
>> > I also agree with folks that there're benefits doing releases more
>> > frequently. Given the historical data, I'd suggest we do quarterly
>> > releases, and maintain three release branches.
>> >
>> > - Jie
>> >
>> > On Fri, Mar 23, 2018 at 10:03 AM, Greg Mann <gr...@mesosphere.io> wrote:
>> >
>> >> The best motivation I can think of for a shorter release cycle is
>> this: if
>> >> the release cadence is fast enough, then developers will be less
>> likely to
>> >> rush a feature into a release. I think this would be a real benefit,
>> since
>> >> rushing features in hurts stability. *However*, I'm not sure if every
>> two
>> >> months is fast enough to bring this benefit. I would imagine that a
>> >> two-month wait is still long enough that people wouldn't want to wait
>> an
>> >> entire release cycle to land their feature. Just off the top of my
>> head, I
>> >> might guess that a release cadence of 1 month or shorter would be often
>> >> enough that it would always seem reasonable for a developer to wait
>> until
>> >> the next release to land a feature. What do y'all think?
>> >>
>> >> Other motivating factors that have been raised are:
>> >> 1) Many users upgrade on a longer timescale than every ~2 months. I
>> think
>> >> that this doesn't need to affect our decision regarding release timing
>> -
>> >> since we guarantee compatibility of all releases with the same major
>> >> version number, there is no reason that a user needs to upgrade minor
>> >> releases one at a time. It's fine to go from 1.N to 1.(N+3), for
>> example.
>> >> 2) Backporting will be a burden if releases are too short. I think
>> that in
>> >> practice, backporting will not take too much longer. If there was a
>> >> conflict back in the tree somewhere, then it's likely that after
>> resolving
>> >> that conflict once, the same diff can be used to backport the change to
>> >> previous releases as well.
>> >> 3) Adhering strictly to a time-based release schedule will help users
>> plan
>> >> their deployments, since they'll be able to rely on features being
>> >> released
>> >> on-schedule. However, if we do strict time-based releases, then it
>> will be
>> >> less certain that a particular feature will land in a particular
>> release,
>> >> and users may have to wait a release cycle to get the feature.
>> >>
>> >> Personally, I find the idea of preventing features from being rushed
>> into
>> >> a
>> >> release very compelling. From that perspective, I would love to see
>> >> releases every month. However, if we're not going to release that
>> often,
>> >> then I think it does make sense to adjust our release schedule to
>> >> accommodate the features that community members want to land in a
>> >> particular release.
>> >>
>> >>
>> >> Jie, I'm curious why you suggest a *minimal* interval between releases.
>> >> Could you elaborate a bit on your motivations there?
>> >>
>> >> Cheers,
>> >> Greg
>> >>
>> >>
>> >> On Fri, Mar 16, 2018 at 2:01 PM, Jie Yu <yu...@gmail.com> wrote:
>> >>
>> >> > Thanks Greg for starting this thread!
>> >> >
>> >> >
>> >> >> My primary motivation here is to bring our documented policy in line
>> >> >> with our practice, whatever that may be
>> >> >
>> >> >
>> >> > +100
>> >> >
>> >> > Do people think that we should attempt to bring our release cadence
>> more
>> >> >> in line with our current stated policy, or should the policy be
>> changed
>> >> >> to reflect our current practice?
>> >> >
>> >> >
>> >> > I think a minor release every 2 months is probably too aggressive. I
>> >> don't
>> >> > have concrete data, but my feeling is that the frequency that folks
>> >> upgrade
>> >> > Mesos is low. I know that many users are still on 1.2.x.
>> >> >
>> >> > I'd actually suggest that we have a *minimal* interval between two
>> >> > releases (e.g., 3 months), and provide some buffer for the release
>> >> process.
>> >> > (so we're expecting about 3 releases per year, this matches what we
>> did
>> >> > last year).
>> >> >
>> >> > And we use our dev sync to coordinate on a release after the minimal
>> >> > release interval has elapsed (and elect a release manager).
>> >> >
>> >> > - Jie
>> >> >
>> >> > On Wed, Mar 14, 2018 at 9:51 AM, Zhitao Li <zh...@gmail.com>
>> >> wrote:
>> >> >
>> >> >> An additional data point is how long it takes from first RC being
>> cut
>> >> to
>> >> >> the final release tag vote passes. That probably indicates
>> smoothness
>> >> of
>> >> >> the release process and how good the quality control measures.
>> >> >>
>> >> >> I would argue for not delaying release for new features and align
>> with
>> >> the
>> >> >> schedule we declared on policy. That makes upstream projects easier
>> to
>> >> >> gauge when a feature will be ready and when they can try it out.
>> >> >>
>> >> >> On Tue, Mar 13, 2018 at 3:10 PM, Greg Mann <gr...@mesosphere.io>
>> wrote:
>> >> >>
>> >> >> > Hi folks,
>> >> >> > During the recent API working group meeting [1], we discussed the
>> >> >> release
>> >> >> > schedule. This has been a recurring topic of discussion in the
>> >> developer
>> >> >> > sync meetings, and while our official policy still specifies
>> >> time-based
>> >> >> > releases at a bi-monthly cadence, in practice we tend to gate our
>> >> >> releases
>> >> >> > on the completion of certain features, and our releases go out on
>> a
>> >> >> > less-frequent basis. Here are the dates of our last few release
>> blog
>> >> >> posts,
>> >> >> > which I'm assuming correlate pretty well with the actual release
>> >> dates:
>> >> >> >
>> >> >> > 1.5.0: 2/8/18
>> >> >> > 1.4.0: 9/18/17
>> >> >> > 1.3.0: 6/7/17
>> >> >> > 1.2.0: 3/8/17
>> >> >> > 1.1.0: 11/10/16
>> >> >> >
>> >> >> > Our current cadence seems to be around 3-4 months between
>> releases,
>> >> >> while
>> >> >> > our documentation states that we release every two months [2]. My
>> >> >> primary
>> >> >> > motivation here is to bring our documented policy in line with our
>> >> >> > practice, whatever that may be. Do people think that we should
>> >> attempt
>> >> >> to
>> >> >> > bring our release cadence more in line with our current stated
>> >> policy,
>> >> >> or
>> >> >> > should the policy be changed to reflect our current practice?
>> >> >> >
>> >> >> > If we were to attempt to align with our stated policy for 1.6.0,
>> >> then we
>> >> >> > would release around April 8, which would probably mean cutting
>> an RC
>> >> >> > sometime around the end of March or beginning of April. This is
>> very
>> >> >> soon!
>> >> >> > :)
>> >> >> >
>> >> >>
>> >> >> > I'm currently working with Gastón on offer operation feedback, and
>> >> I'm
>> >> >> not
>> >> >> > sure that we would have it ready in time for an early April
>> release
>> >> >> date.
>> >> >> > Personally, I would be OK with this, since we could land the
>> feature
>> >> in
>> >> >> > 1.7.0 in June. However, I'm not sure how well this schedule would
>> >> work
>> >> >> for
>> >> >> > the features that other people are currently working on.
>> >> >> >
>> >> >>
>> >> >> A highly important feature our org need is resizing of persistent
>> >> volume.
>> >> >> I
>> >> >> think it has a good chance to make the stated 1.6 schedule.
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > I'm curious to hear people's thoughts on this, developers and
>> users
>> >> >> alike!
>> >> >> >
>> >> >> > Cheers,
>> >> >> > Greg
>> >> >> >
>> >> >> >
>> >> >> > [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgD
>> >> >> > G62ifn0cZIBWw1f_Ler6fLM/edit#
>> >> >> > [2] http://mesos.apache.org/documentation/latest/versioning/
>> >> >> > #release-schedule
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Cheers,
>> >> >>
>> >> >> Zhitao Li
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>

Re: Release policy and 1.6 release schedule

[Greg Mann <gr...@mesosphere.io>]

Thanks for the reviews, y'all! I've got a few "Ship-Its" - I'll commit this
later today unless I hear any objections.

Cheers,
Greg

On Wed, Apr 4, 2018 at 11:49 AM, Greg Mann <gr...@mesosphere.io> wrote:

> Hey folks,
> I've posted a proposed update to our documented release schedule:
> https://reviews.apache.org/r/66454/
>
> Please take a look and comment!
>
> Cheers,
> Greg
>
>
> On Mon, Mar 26, 2018 at 11:34 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
>> +1 for quarterly. I would also say that we should support 3 releases at
>> any given time, regardless of the duration that implies. If there are no
>> objections, I'll submit a patch to update our docs to this effect. I think
>> that slowing down our documented cadence a bit will give us a chance to
>> faithfully adhere to our stated policy.
>>
>> Alex, I agree that releasing monthly would be great if we had better
>> automation. This is something we can work toward in the future I hope :)
>>
>> Cheers,
>> Greg
>>
>> On Mon, Mar 26, 2018 at 6:49 AM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> I would like us to do monthly releases and support 10 branches at a time.
>>> Ideally, releasing that often reduces the burden for the release manager,
>>> because there are less changes and less new features. However, we lack
>>> automation to support this pace: our release guide [1] is several pages
>>> long and includes quite a few non-trivial steps. It would be great to
>>> find
>>> some time (maybe during the next Mesos hackathon?) and revisit our
>>> release
>>> procedures, but until then I'm +1 for quarterly.
>>>
>>> [1] https://mesos.apache.org/documentation/latest/release-guide/
>>>
>>> On Sat, Mar 24, 2018 at 5:48 AM, Vinod Kone <vi...@gmail.com> wrote:
>>>
>>> > I’m +1 for quarterly.
>>> >
>>> > Most importantly I want us to adhere to a predictable cadence.
>>> >
>>> > Sent from my phone
>>> >
>>> > On Mar 23, 2018, at 9:21 PM, Jie Yu <yu...@gmail.com> wrote:
>>> >
>>> > It's a burden for supporting multiple releases.
>>> >
>>> > 1.2 was released March, 2017 (1 year ago), and I know that some users
>>> are
>>> > still on that version
>>> > 1.3 was released June, 2017 (9 months ago), and we're still
>>> maintaining it
>>> > (still backport patches
>>> > <https://github.com/apache/mesos/commit/064f64552624e38d5dd9
>>> 2660eef6f6940128c106> several
>>> > days ago, which some users asked)
>>> > 1.4 was released Sept, 2017 (6 months ago).
>>> > 1.5 was released Feb, 2018 (1 month ago).
>>> >
>>> > As you can see, users expect a release to be supported 6-9 months
>>> (e.g.,
>>> > backports are still needed for 1.3 release, which is 9 months old). If
>>> we
>>> > were to do monthly minor release, we'll probably need to maintain 6-9
>>> > release branches? That's too much of an ask for committers and
>>> maintainers.
>>> >
>>> > I also agree with folks that there're benefits doing releases more
>>> > frequently. Given the historical data, I'd suggest we do quarterly
>>> > releases, and maintain three release branches.
>>> >
>>> > - Jie
>>> >
>>> > On Fri, Mar 23, 2018 at 10:03 AM, Greg Mann <gr...@mesosphere.io>
>>> wrote:
>>> >
>>> >> The best motivation I can think of for a shorter release cycle is
>>> this: if
>>> >> the release cadence is fast enough, then developers will be less
>>> likely to
>>> >> rush a feature into a release. I think this would be a real benefit,
>>> since
>>> >> rushing features in hurts stability. *However*, I'm not sure if every
>>> two
>>> >> months is fast enough to bring this benefit. I would imagine that a
>>> >> two-month wait is still long enough that people wouldn't want to wait
>>> an
>>> >> entire release cycle to land their feature. Just off the top of my
>>> head, I
>>> >> might guess that a release cadence of 1 month or shorter would be
>>> often
>>> >> enough that it would always seem reasonable for a developer to wait
>>> until
>>> >> the next release to land a feature. What do y'all think?
>>> >>
>>> >> Other motivating factors that have been raised are:
>>> >> 1) Many users upgrade on a longer timescale than every ~2 months. I
>>> think
>>> >> that this doesn't need to affect our decision regarding release
>>> timing -
>>> >> since we guarantee compatibility of all releases with the same major
>>> >> version number, there is no reason that a user needs to upgrade minor
>>> >> releases one at a time. It's fine to go from 1.N to 1.(N+3), for
>>> example.
>>> >> 2) Backporting will be a burden if releases are too short. I think
>>> that in
>>> >> practice, backporting will not take too much longer. If there was a
>>> >> conflict back in the tree somewhere, then it's likely that after
>>> resolving
>>> >> that conflict once, the same diff can be used to backport the change
>>> to
>>> >> previous releases as well.
>>> >> 3) Adhering strictly to a time-based release schedule will help users
>>> plan
>>> >> their deployments, since they'll be able to rely on features being
>>> >> released
>>> >> on-schedule. However, if we do strict time-based releases, then it
>>> will be
>>> >> less certain that a particular feature will land in a particular
>>> release,
>>> >> and users may have to wait a release cycle to get the feature.
>>> >>
>>> >> Personally, I find the idea of preventing features from being rushed
>>> into
>>> >> a
>>> >> release very compelling. From that perspective, I would love to see
>>> >> releases every month. However, if we're not going to release that
>>> often,
>>> >> then I think it does make sense to adjust our release schedule to
>>> >> accommodate the features that community members want to land in a
>>> >> particular release.
>>> >>
>>> >>
>>> >> Jie, I'm curious why you suggest a *minimal* interval between
>>> releases.
>>> >> Could you elaborate a bit on your motivations there?
>>> >>
>>> >> Cheers,
>>> >> Greg
>>> >>
>>> >>
>>> >> On Fri, Mar 16, 2018 at 2:01 PM, Jie Yu <yu...@gmail.com> wrote:
>>> >>
>>> >> > Thanks Greg for starting this thread!
>>> >> >
>>> >> >
>>> >> >> My primary motivation here is to bring our documented policy in
>>> line
>>> >> >> with our practice, whatever that may be
>>> >> >
>>> >> >
>>> >> > +100
>>> >> >
>>> >> > Do people think that we should attempt to bring our release cadence
>>> more
>>> >> >> in line with our current stated policy, or should the policy be
>>> changed
>>> >> >> to reflect our current practice?
>>> >> >
>>> >> >
>>> >> > I think a minor release every 2 months is probably too aggressive. I
>>> >> don't
>>> >> > have concrete data, but my feeling is that the frequency that folks
>>> >> upgrade
>>> >> > Mesos is low. I know that many users are still on 1.2.x.
>>> >> >
>>> >> > I'd actually suggest that we have a *minimal* interval between two
>>> >> > releases (e.g., 3 months), and provide some buffer for the release
>>> >> process.
>>> >> > (so we're expecting about 3 releases per year, this matches what we
>>> did
>>> >> > last year).
>>> >> >
>>> >> > And we use our dev sync to coordinate on a release after the minimal
>>> >> > release interval has elapsed (and elect a release manager).
>>> >> >
>>> >> > - Jie
>>> >> >
>>> >> > On Wed, Mar 14, 2018 at 9:51 AM, Zhitao Li <zh...@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> >> An additional data point is how long it takes from first RC being
>>> cut
>>> >> to
>>> >> >> the final release tag vote passes. That probably indicates
>>> smoothness
>>> >> of
>>> >> >> the release process and how good the quality control measures.
>>> >> >>
>>> >> >> I would argue for not delaying release for new features and align
>>> with
>>> >> the
>>> >> >> schedule we declared on policy. That makes upstream projects
>>> easier to
>>> >> >> gauge when a feature will be ready and when they can try it out.
>>> >> >>
>>> >> >> On Tue, Mar 13, 2018 at 3:10 PM, Greg Mann <gr...@mesosphere.io>
>>> wrote:
>>> >> >>
>>> >> >> > Hi folks,
>>> >> >> > During the recent API working group meeting [1], we discussed the
>>> >> >> release
>>> >> >> > schedule. This has been a recurring topic of discussion in the
>>> >> developer
>>> >> >> > sync meetings, and while our official policy still specifies
>>> >> time-based
>>> >> >> > releases at a bi-monthly cadence, in practice we tend to gate our
>>> >> >> releases
>>> >> >> > on the completion of certain features, and our releases go out
>>> on a
>>> >> >> > less-frequent basis. Here are the dates of our last few release
>>> blog
>>> >> >> posts,
>>> >> >> > which I'm assuming correlate pretty well with the actual release
>>> >> dates:
>>> >> >> >
>>> >> >> > 1.5.0: 2/8/18
>>> >> >> > 1.4.0: 9/18/17
>>> >> >> > 1.3.0: 6/7/17
>>> >> >> > 1.2.0: 3/8/17
>>> >> >> > 1.1.0: 11/10/16
>>> >> >> >
>>> >> >> > Our current cadence seems to be around 3-4 months between
>>> releases,
>>> >> >> while
>>> >> >> > our documentation states that we release every two months [2]. My
>>> >> >> primary
>>> >> >> > motivation here is to bring our documented policy in line with
>>> our
>>> >> >> > practice, whatever that may be. Do people think that we should
>>> >> attempt
>>> >> >> to
>>> >> >> > bring our release cadence more in line with our current stated
>>> >> policy,
>>> >> >> or
>>> >> >> > should the policy be changed to reflect our current practice?
>>> >> >> >
>>> >> >> > If we were to attempt to align with our stated policy for 1.6.0,
>>> >> then we
>>> >> >> > would release around April 8, which would probably mean cutting
>>> an RC
>>> >> >> > sometime around the end of March or beginning of April. This is
>>> very
>>> >> >> soon!
>>> >> >> > :)
>>> >> >> >
>>> >> >>
>>> >> >> > I'm currently working with Gastón on offer operation feedback,
>>> and
>>> >> I'm
>>> >> >> not
>>> >> >> > sure that we would have it ready in time for an early April
>>> release
>>> >> >> date.
>>> >> >> > Personally, I would be OK with this, since we could land the
>>> feature
>>> >> in
>>> >> >> > 1.7.0 in June. However, I'm not sure how well this schedule would
>>> >> work
>>> >> >> for
>>> >> >> > the features that other people are currently working on.
>>> >> >> >
>>> >> >>
>>> >> >> A highly important feature our org need is resizing of persistent
>>> >> volume.
>>> >> >> I
>>> >> >> think it has a good chance to make the stated 1.6 schedule.
>>> >> >>
>>> >> >>
>>> >> >> >
>>> >> >> > I'm curious to hear people's thoughts on this, developers and
>>> users
>>> >> >> alike!
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> > Greg
>>> >> >> >
>>> >> >> >
>>> >> >> > [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgD
>>> >> >> > G62ifn0cZIBWw1f_Ler6fLM/edit#
>>> >> >> > [2] http://mesos.apache.org/documentation/latest/versioning/
>>> >> >> > #release-schedule
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cheers,
>>> >> >>
>>> >> >> Zhitao Li
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>

Re: Release policy and 1.6 release schedule

[Greg Mann <gr...@mesosphere.io>]

Thanks for the reviews, y'all! I've got a few "Ship-Its" - I'll commit this
later today unless I hear any objections.

Cheers,
Greg

On Wed, Apr 4, 2018 at 11:49 AM, Greg Mann <gr...@mesosphere.io> wrote:

> Hey folks,
> I've posted a proposed update to our documented release schedule:
> https://reviews.apache.org/r/66454/
>
> Please take a look and comment!
>
> Cheers,
> Greg
>
>
> On Mon, Mar 26, 2018 at 11:34 AM, Greg Mann <gr...@mesosphere.io> wrote:
>
>> +1 for quarterly. I would also say that we should support 3 releases at
>> any given time, regardless of the duration that implies. If there are no
>> objections, I'll submit a patch to update our docs to this effect. I think
>> that slowing down our documented cadence a bit will give us a chance to
>> faithfully adhere to our stated policy.
>>
>> Alex, I agree that releasing monthly would be great if we had better
>> automation. This is something we can work toward in the future I hope :)
>>
>> Cheers,
>> Greg
>>
>> On Mon, Mar 26, 2018 at 6:49 AM, Alex Rukletsov <al...@mesosphere.com>
>> wrote:
>>
>>> I would like us to do monthly releases and support 10 branches at a time.
>>> Ideally, releasing that often reduces the burden for the release manager,
>>> because there are less changes and less new features. However, we lack
>>> automation to support this pace: our release guide [1] is several pages
>>> long and includes quite a few non-trivial steps. It would be great to
>>> find
>>> some time (maybe during the next Mesos hackathon?) and revisit our
>>> release
>>> procedures, but until then I'm +1 for quarterly.
>>>
>>> [1] https://mesos.apache.org/documentation/latest/release-guide/
>>>
>>> On Sat, Mar 24, 2018 at 5:48 AM, Vinod Kone <vi...@gmail.com> wrote:
>>>
>>> > I’m +1 for quarterly.
>>> >
>>> > Most importantly I want us to adhere to a predictable cadence.
>>> >
>>> > Sent from my phone
>>> >
>>> > On Mar 23, 2018, at 9:21 PM, Jie Yu <yu...@gmail.com> wrote:
>>> >
>>> > It's a burden for supporting multiple releases.
>>> >
>>> > 1.2 was released March, 2017 (1 year ago), and I know that some users
>>> are
>>> > still on that version
>>> > 1.3 was released June, 2017 (9 months ago), and we're still
>>> maintaining it
>>> > (still backport patches
>>> > <https://github.com/apache/mesos/commit/064f64552624e38d5dd9
>>> 2660eef6f6940128c106> several
>>> > days ago, which some users asked)
>>> > 1.4 was released Sept, 2017 (6 months ago).
>>> > 1.5 was released Feb, 2018 (1 month ago).
>>> >
>>> > As you can see, users expect a release to be supported 6-9 months
>>> (e.g.,
>>> > backports are still needed for 1.3 release, which is 9 months old). If
>>> we
>>> > were to do monthly minor release, we'll probably need to maintain 6-9
>>> > release branches? That's too much of an ask for committers and
>>> maintainers.
>>> >
>>> > I also agree with folks that there're benefits doing releases more
>>> > frequently. Given the historical data, I'd suggest we do quarterly
>>> > releases, and maintain three release branches.
>>> >
>>> > - Jie
>>> >
>>> > On Fri, Mar 23, 2018 at 10:03 AM, Greg Mann <gr...@mesosphere.io>
>>> wrote:
>>> >
>>> >> The best motivation I can think of for a shorter release cycle is
>>> this: if
>>> >> the release cadence is fast enough, then developers will be less
>>> likely to
>>> >> rush a feature into a release. I think this would be a real benefit,
>>> since
>>> >> rushing features in hurts stability. *However*, I'm not sure if every
>>> two
>>> >> months is fast enough to bring this benefit. I would imagine that a
>>> >> two-month wait is still long enough that people wouldn't want to wait
>>> an
>>> >> entire release cycle to land their feature. Just off the top of my
>>> head, I
>>> >> might guess that a release cadence of 1 month or shorter would be
>>> often
>>> >> enough that it would always seem reasonable for a developer to wait
>>> until
>>> >> the next release to land a feature. What do y'all think?
>>> >>
>>> >> Other motivating factors that have been raised are:
>>> >> 1) Many users upgrade on a longer timescale than every ~2 months. I
>>> think
>>> >> that this doesn't need to affect our decision regarding release
>>> timing -
>>> >> since we guarantee compatibility of all releases with the same major
>>> >> version number, there is no reason that a user needs to upgrade minor
>>> >> releases one at a time. It's fine to go from 1.N to 1.(N+3), for
>>> example.
>>> >> 2) Backporting will be a burden if releases are too short. I think
>>> that in
>>> >> practice, backporting will not take too much longer. If there was a
>>> >> conflict back in the tree somewhere, then it's likely that after
>>> resolving
>>> >> that conflict once, the same diff can be used to backport the change
>>> to
>>> >> previous releases as well.
>>> >> 3) Adhering strictly to a time-based release schedule will help users
>>> plan
>>> >> their deployments, since they'll be able to rely on features being
>>> >> released
>>> >> on-schedule. However, if we do strict time-based releases, then it
>>> will be
>>> >> less certain that a particular feature will land in a particular
>>> release,
>>> >> and users may have to wait a release cycle to get the feature.
>>> >>
>>> >> Personally, I find the idea of preventing features from being rushed
>>> into
>>> >> a
>>> >> release very compelling. From that perspective, I would love to see
>>> >> releases every month. However, if we're not going to release that
>>> often,
>>> >> then I think it does make sense to adjust our release schedule to
>>> >> accommodate the features that community members want to land in a
>>> >> particular release.
>>> >>
>>> >>
>>> >> Jie, I'm curious why you suggest a *minimal* interval between
>>> releases.
>>> >> Could you elaborate a bit on your motivations there?
>>> >>
>>> >> Cheers,
>>> >> Greg
>>> >>
>>> >>
>>> >> On Fri, Mar 16, 2018 at 2:01 PM, Jie Yu <yu...@gmail.com> wrote:
>>> >>
>>> >> > Thanks Greg for starting this thread!
>>> >> >
>>> >> >
>>> >> >> My primary motivation here is to bring our documented policy in
>>> line
>>> >> >> with our practice, whatever that may be
>>> >> >
>>> >> >
>>> >> > +100
>>> >> >
>>> >> > Do people think that we should attempt to bring our release cadence
>>> more
>>> >> >> in line with our current stated policy, or should the policy be
>>> changed
>>> >> >> to reflect our current practice?
>>> >> >
>>> >> >
>>> >> > I think a minor release every 2 months is probably too aggressive. I
>>> >> don't
>>> >> > have concrete data, but my feeling is that the frequency that folks
>>> >> upgrade
>>> >> > Mesos is low. I know that many users are still on 1.2.x.
>>> >> >
>>> >> > I'd actually suggest that we have a *minimal* interval between two
>>> >> > releases (e.g., 3 months), and provide some buffer for the release
>>> >> process.
>>> >> > (so we're expecting about 3 releases per year, this matches what we
>>> did
>>> >> > last year).
>>> >> >
>>> >> > And we use our dev sync to coordinate on a release after the minimal
>>> >> > release interval has elapsed (and elect a release manager).
>>> >> >
>>> >> > - Jie
>>> >> >
>>> >> > On Wed, Mar 14, 2018 at 9:51 AM, Zhitao Li <zh...@gmail.com>
>>> >> wrote:
>>> >> >
>>> >> >> An additional data point is how long it takes from first RC being
>>> cut
>>> >> to
>>> >> >> the final release tag vote passes. That probably indicates
>>> smoothness
>>> >> of
>>> >> >> the release process and how good the quality control measures.
>>> >> >>
>>> >> >> I would argue for not delaying release for new features and align
>>> with
>>> >> the
>>> >> >> schedule we declared on policy. That makes upstream projects
>>> easier to
>>> >> >> gauge when a feature will be ready and when they can try it out.
>>> >> >>
>>> >> >> On Tue, Mar 13, 2018 at 3:10 PM, Greg Mann <gr...@mesosphere.io>
>>> wrote:
>>> >> >>
>>> >> >> > Hi folks,
>>> >> >> > During the recent API working group meeting [1], we discussed the
>>> >> >> release
>>> >> >> > schedule. This has been a recurring topic of discussion in the
>>> >> developer
>>> >> >> > sync meetings, and while our official policy still specifies
>>> >> time-based
>>> >> >> > releases at a bi-monthly cadence, in practice we tend to gate our
>>> >> >> releases
>>> >> >> > on the completion of certain features, and our releases go out
>>> on a
>>> >> >> > less-frequent basis. Here are the dates of our last few release
>>> blog
>>> >> >> posts,
>>> >> >> > which I'm assuming correlate pretty well with the actual release
>>> >> dates:
>>> >> >> >
>>> >> >> > 1.5.0: 2/8/18
>>> >> >> > 1.4.0: 9/18/17
>>> >> >> > 1.3.0: 6/7/17
>>> >> >> > 1.2.0: 3/8/17
>>> >> >> > 1.1.0: 11/10/16
>>> >> >> >
>>> >> >> > Our current cadence seems to be around 3-4 months between
>>> releases,
>>> >> >> while
>>> >> >> > our documentation states that we release every two months [2]. My
>>> >> >> primary
>>> >> >> > motivation here is to bring our documented policy in line with
>>> our
>>> >> >> > practice, whatever that may be. Do people think that we should
>>> >> attempt
>>> >> >> to
>>> >> >> > bring our release cadence more in line with our current stated
>>> >> policy,
>>> >> >> or
>>> >> >> > should the policy be changed to reflect our current practice?
>>> >> >> >
>>> >> >> > If we were to attempt to align with our stated policy for 1.6.0,
>>> >> then we
>>> >> >> > would release around April 8, which would probably mean cutting
>>> an RC
>>> >> >> > sometime around the end of March or beginning of April. This is
>>> very
>>> >> >> soon!
>>> >> >> > :)
>>> >> >> >
>>> >> >>
>>> >> >> > I'm currently working with Gastón on offer operation feedback,
>>> and
>>> >> I'm
>>> >> >> not
>>> >> >> > sure that we would have it ready in time for an early April
>>> release
>>> >> >> date.
>>> >> >> > Personally, I would be OK with this, since we could land the
>>> feature
>>> >> in
>>> >> >> > 1.7.0 in June. However, I'm not sure how well this schedule would
>>> >> work
>>> >> >> for
>>> >> >> > the features that other people are currently working on.
>>> >> >> >
>>> >> >>
>>> >> >> A highly important feature our org need is resizing of persistent
>>> >> volume.
>>> >> >> I
>>> >> >> think it has a good chance to make the stated 1.6 schedule.
>>> >> >>
>>> >> >>
>>> >> >> >
>>> >> >> > I'm curious to hear people's thoughts on this, developers and
>>> users
>>> >> >> alike!
>>> >> >> >
>>> >> >> > Cheers,
>>> >> >> > Greg
>>> >> >> >
>>> >> >> >
>>> >> >> > [1] https://docs.google.com/document/d/1JrF7pA6gcBZ6iyeP5YgD
>>> >> >> > G62ifn0cZIBWw1f_Ler6fLM/edit#
>>> >> >> > [2] http://mesos.apache.org/documentation/latest/versioning/
>>> >> >> > #release-schedule
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Cheers,
>>> >> >>
>>> >> >> Zhitao Li
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>