On 09/06/2017 04:23 PM, Sage Weil wrote:
* Keep even/odd pattern, but force a 'train' model with a more regular
cadence
+ predictable schedule
- some features will miss the target and be delayed a year
Personally, I think a predictable schedule is the way to go. Two major
reasons come to mind:
1. Developers are actually aware of what the cut-off date is, and will
plan accordingly; and,
2. Downstreams will have a better notion of when the next release is to
be expected, and plan accordingly.
However, a one year wait for a release may be a can of worms waiting to
be opened. Even though it would ideally provide us a lot more time to
merge stuff and test it, there's also the downside that some stuff may
be pushed further and further down the line, and eventually merged just
before the window closes.
For that, I'd argue having an intermediate (staging?) release could be
helpful, but I fear it would not be anything more than any other
dev-release. Therefore, if we stick to a one-year cadence, let's have
frequent dev-releases.
I would also like to argue for a hard cut-off date considerably before
major holiday seasons. Because no one really wants to be dealing with
bugs or releasing software while a considerable portion of developers
are away.
Additionally,
* Drop the odd releases, but relax the "must upgrade through every LTS" to
allow upgrades across 2 versions (e.g., luminous -> mimic or luminous ->
nautilus). Shorten release cycle (~6-9 months).
I can be on board with this too. As long as we have a very clear cut-off
date regardless.
-Joao
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
