mesos-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Mann <g...@mesosphere.io>
Subject Re: Release policy and 1.6 release schedule
Date Wed, 04 Apr 2018 18:49:55 GMT
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 <greg@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 <alex@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 <vinodkone@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 <yujie.jay@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 <greg@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 <yujie.jay@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 <zhitaoli.cs@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 <greg@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
>> >> >>
>> >> >
>> >> >
>> >>
>> >
>> >
>>
>
>

Mime
View raw message