A big +1 to Lars proposal. Having the train run on time (3 months) has many benefits. Take a look at the Kuberenetes release cycle for reference (https://github.com/kubernetes/community/wiki/Life-of-a-Kubernetes-Release) and its one of the highest velocity projects and they do stateful, breaking and protocol upgrades too. > These make the upgrade testing a huge concern and burden for the > Ceph development community. > Sage, do you think an investment in more automation around upgrade testing would help this? Limiting the horizon to a ~1 year could help too. > - test upgrades between all of them within a 2 year horizon, instead > of just the last major one > If you limit the upgrade horizon to 2 previous versions, a customer on n-3 could upgrade to n-2 and then to n. Also I think by declaring the policy most admins will start upgrading more frequently. My 2 cents. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
