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 Mon, 26 Mar 2018 18:34:48 GMT
+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/064f64552624e38d5dd92660eef6f6
> 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 <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