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 >
