> > 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.
I think the burden of maintaining a release branch is not just backporting. We need to run CI to make sure every maintained release branch are working, and do testing for that. It's a burden if there are too many release branches. - Jie On Fri, 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/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 >> >> >> > >> > >> > >
