"This scheme does not necessarily dictate that live or rolling upgrades need to be supported between tick releases. Meaning RPC compatibility between N to N-1 guarantees can remain, resulting in deployments that are on a tick-tick release schedule requiring some downtime during an upgrade because components will be spanning more than two actual releases."
From the perspective of deployment tools, this would mean needing to support two different upgrade strategies. Given the constraints around DB migrations, would it be too much effort for projects to also support N-2 to N RPC compatibility?
I can tell you it's much harder to do it for RPC than DB migrations. I personally think it's too much to ask projects to move to that right away, even though some may be able to do it now. It also has farther reaches than you might expect, such as dependent components that change over time (think OVS/OVN, libvirt, qemu).
It may just be the early morning and lack of caffeination, but I'm not sure what the deployment concern is exactly. You rely entirely on live rolling upgrades today? Presumably only for some of the services?
--Dan