Re: Release policy and 1.6 release schedule

+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

Re: Release policy and 1.6 release schedule

> > 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. > > That's a good point, we do need to run CI on all

Re: Support deadline for tasks

Hi, Benjamin, Usually for us if tasks run longer than a certain period of time it means that something has gone wrong and we should just abort/try again. David (also at Yelp) On Fri, Mar 23, 2018 at 7:14 PM, Benjamin Mahler wrote: > Ah, I was more curious about why they

Re: Release policy and 1.6 release schedule

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