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 >> >> >> >> >> > >> >> > >> >> >> > >> > >> > >