> Using this approach I think we can support live upgrades from N-1 to N > while still being able to drop some backwards compatibility code each > release cycle.
Agreed. We've been kinda slack about bumping the RPC majors for a while, which means we end up with a lot of cruft and comments like "#NOTE: Remove this in Grizzly" still in the code. Major numbers are free, we should use them more :) > Thoughts? I wonder if it's worth also saying something in the checklist about "if the API hasn't changed in this release, no need to bump". Just so we don't get to RPC version 23.0 for the console API, or something else that doesn't change much. I don't have a feeling for how this would translate to objects, if at all, so I'll reserve judgment on that for the moment. Mechanically, it's a very similar thing, but we've not had enough churn in the object APIs to know if being this proactive is at all warranted. --Dan _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
