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/064f64552624e38d5dd92660eef6f6940128c106> 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 > >> > > > > >
