>>>>> Don't forget we also need to keep building for older distros. I know >>>> can we be more specific about this requirement? are you saying that >>>> the R release still needs to build on ubuntu focal? or that our >>>> octopus/pacific/quincy releases do? >>> I was thinking we need to maintain support for Ubuntu 20.04 in our >>> next release, yeah. But that may not be right; I guess we generally >>> try and support the most recent LTS in our new branches. So maybe this >>> is a non-issue? >> okay thanks, i see what you mean. i think it would be ideal if we >> could drop focal packages from all of our upstream releases. but if we >> can't do that yet, we could continue building earlier releases in >> focal so long as we avoid backporting any changes that require c++20. >> i believe that's how we handled the switches to c++11 and 17 in the >> past. though if we *can* drop focal entirely, that would make it a lot >> easier to adopt the new c++20 features I’m a bit saddened by that idea. I do understand the desire to be free of older dependencies (Trusty got realllly old in that respect), and that adoption of container deployments (NOT looking to relitigate that) can help decouple the application from the underlying platform for those situations where it’s feasible. Many deployments, though, *can’t* update their OS (or Ceph for that matter) to the latest release in short order even if they want to. At fleet scale automation and monitoring is complex and must accommodate many other roles in addition to Ceph. Testing, qualifying, and iterating upgrades takes time, and it’s not unusual to have a year after an LTS for shakeout and to work in all the peices required — especially in cases where an in-situ upgrade isn’t feasible and the entire node gets re-imaged. Focal came out … less than two years ago. IMHO that’s an unreasonably short timeline for obsolescence, especially when Jammy isn’t due until late April — and enterprises are likely to wait for at least one dot release before deploying. Heck, there are lots of people who have only recently been able to roll out Bionic. Respectfully, sometimes we need to consider the lifecycle for existing clusters as well as for greenfield deployments. — aad _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
