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