Re: Release policy and 1.6 release schedule

Thanks for the reviews, y'all! I've got a few "Ship-Its" - I'll commit this later today unless I hear any objections. Cheers, Greg On Wed, Apr 4, 2018 at 11:49 AM, Greg Mann wrote: > Hey folks, > I've posted a proposed update to our documented release schedule: >

Re: Release policy and 1.6 release schedule

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 wrote: > +1 for quarterly. I would also say that we should support 3

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

Re: Release policy and 1.6 release schedule

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 wrote: > > It's a burden for supporting multiple releases. > > 1.2 was released March, 2017 (1 year ago), and I know that some

Re: Release policy and 1.6 release schedule

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

Re: Release policy and 1.6 release schedule

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

Re: Release policy and 1.6 release schedule

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

Re: Release policy and 1.6 release schedule

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

Re: Release policy and 1.6 release schedule

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

Release policy and 1.6 release schedule

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