mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Rukletsov <a...@mesosphere.com>
Subject Re: Release policy and 1.6 release schedule
Date Mon, 26 Mar 2018 13:49:30 GMT
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/064f64552624e38d5dd92660eef6f6940128c106>
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message