Thanks for the reviews, y'all! I've got a few "Ship-Its" - I'll commit this later today unless I hear any objections.
Cheers, Greg On Wed, Apr 4, 2018 at 11:49 AM, Greg Mann <g...@mesosphere.io> wrote: > Hey folks, > I've posted a proposed update to our documented release schedule: > https://reviews.apache.org/r/66454/ > > Please take a look and comment! > > Cheers, > Greg > > > On Mon, Mar 26, 2018 at 11:34 AM, Greg Mann <g...@mesosphere.io> wrote: > >> +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 <a...@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 <vinodk...@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....@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/064f64552624e38d5dd9 >>> 2660eef6f6940128c106> 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 <g...@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....@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...@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 <g...@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 >>> >> >> >>> >> > >>> >> > >>> >> >>> > >>> > >>> >> >> >
