Re: Release policy and 1.6 release schedule

[Greg Mann]

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

Re: Release policy and 1.6 release schedule

[Greg Mann]

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

Re: Release policy and 1.6 release schedule

[Greg Mann]

+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  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  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  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
> >  940128c106> 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  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 

Re: Release policy and 1.6 release schedule

[Greg Mann]

>
> I think the burden of maintaining a release branch is not just
> backporting. We need to run CI to make sure every maintained release branch
> are working, and do testing for that. It's a burden if there are too many
> release branches.
>
>
 That's a good point, we do need to run CI on all supported versions.
However, I think that updates to the release branches are not nearly as
frequent as updates to master branch. So, I think it might actually be
reasonable to run CI on ~10 release branches, since we will only need to
run it when bug fixes get backported.

Re: Release policy and 1.6 release schedule

[Alex Rukletsov]

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

Re: Release policy and 1.6 release schedule

[Vinod Kone]

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

Re: Release policy and 1.6 release schedule

[Jie Yu]

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


I think the burden of maintaining a release branch is not just backporting.
We need to run CI to make sure every maintained release branch are working,
and do testing for that. It's a burden if there are too many release
branches.

- Jie

On Fri, Mar 23, 2018 at 9:21 PM, Jie Yu  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
> 
>  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  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  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 

Re: Release policy and 1.6 release schedule

[Jie Yu]

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

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

Re: Release policy and 1.6 release schedule

[Greg Mann]

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

Re: Release policy and 1.6 release schedule

[Zhitao Li]

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