mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhitao Li <>
Subject Re: Release policy and 1.6 release schedule
Date Wed, 14 Mar 2018 16:51:03 GMT
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


Zhitao Li

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