mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Mann <>
Subject Re: Release policy and 1.6 release schedule
Date Fri, 23 Mar 2018 17:03:01 GMT
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?


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 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]
>> > G62ifn0cZIBWw1f_Ler6fLM/edit#
>> > [2]
>> > #release-schedule
>> >
>> --
>> Cheers,
>> Zhitao Li

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message