We go with upstream release and mostly Nautilus now, probably the most aggressive ones among serious production user (i.e tens of PB+ ),
I will vote for November for several reasons: 1. Q4 is holiday season and usually production rollout was blocked , especially storage related change, which usually give team more time to prepare/ testing/ LnP the new releases, as well as catch up with new features. 2. Q4/Q1 is usually the planning season, having the upstream released and testing to know the readiness of new feature, will greatly helps when planning the feature/offering of next year. 3. Users have whole year to migrate their provision/monitoring/deployment/remediation system to new version, and have enough time to fix and stable the surrounding system before next holiday season. Release in Feb or March will make the Q4 just in the middle of the cycle, and lot of changes will land at last minutes(month), in which case, few things can be test and forecasted based on the state-of-art in Q4. -Xiaoxi Linh Vu <v...@unimelb.edu.au> 于2019年6月6日周四 上午8:32写道： > > I think 12 months cycle is much better from the cluster operations > perspective. I also like March as a release month as well. > ________________________________ > From: ceph-users <ceph-users-boun...@lists.ceph.com> on behalf of Sage Weil > <s...@newdream.net> > Sent: Thursday, 6 June 2019 1:57 AM > To: ceph-us...@ceph.com; ceph-de...@vger.kernel.org; d...@ceph.io > Subject: [ceph-users] Changing the release cadence > > Hi everyone, > > Since luminous, we have had the follow release cadence and policy: > - release every 9 months > - maintain backports for the last two releases > - enable upgrades to move either 1 or 2 releases heads > (e.g., luminous -> mimic or nautilus; mimic -> nautilus or octopus; ...) > > This has mostly worked out well, except that the mimic release received > less attention that we wanted due to the fact that multiple downstream > Ceph products (from Red Has and SUSE) decided to based their next release > on nautilus. Even though upstream every release is an "LTS" release, as a > practical matter mimic got less attention than luminous or nautilus. > > We've had several requests/proposals to shift to a 12 month cadence. This > has several advantages: > > - Stable/conservative clusters only have to be upgraded every 2 years > (instead of every 18 months) > - Yearly releases are more likely to intersect with downstream > distribution release (e.g., Debian). In the past there have been > problems where the Ceph releases included in consecutive releases of a > distro weren't easily upgradeable. > - Vendors that make downstream Ceph distributions/products tend to > release yearly. Aligning with those vendors means they are more likely > to productize *every* Ceph release. This will help make every Ceph > release an "LTS" release (not just in name but also in terms of > maintenance attention). > > So far the balance of opinion seems to favor a shift to a 12 month > cycle[1], especially among developers, so it seems pretty likely we'll > make that shift. (If you do have strong concerns about such a move, now > is the time to raise them.) > > That brings us to an important decision: what time of year should we > release? Once we pick the timing, we'll be releasing at that time *every > year* for each release (barring another schedule shift, which we want to > avoid), so let's choose carefully! > > A few options: > > - November: If we release Octopus 9 months from the Nautilus release > (planned for Feb, released in Mar) then we'd target this November. We > could shift to a 12 months candence after that. > - February: That's 12 months from the Nautilus target. > - March: That's 12 months from when Nautilus was *actually* released. > > November is nice in the sense that we'd wrap things up before the > holidays. It's less good in that users may not be inclined to install the > new release when many developers will be less available in December. > > February kind of sucked in that the scramble to get the last few things > done happened during the holidays. OTOH, we should be doing what we can > to avoid such scrambles, so that might not be something we should factor > in. March may be a bit more balanced, with a solid 3 months before when > people are productive, and 3 months after before they disappear on holiday > to address any post-release issues. > > People tend to be somewhat less available over the summer months due to > holidays etc, so an early or late summer release might also be less than > ideal. > > Thoughts? If we can narrow it down to a few options maybe we could do a > poll to gauge user preferences. > > Thanks! > sage > > > [1] > https://protect-au.mimecast.com/s/N1l6CROAEns1RN1Zu9Jwts?domain=twitter.com > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > > _______________________________________________ > ceph-users mailing list > ceph-users@lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com _______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
