mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vinod Kone <vinodk...@gmail.com>
Subject Re: Release policy and 1.6 release schedule
Date Sat, 24 Mar 2018 04:48:41 GMT
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 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, 7-Bit, 0 bytes)
View raw message