> So if we make backwards incompatible changes we really need a major > version bump. Minor versions don't cut it, because the expectation is > you have API stability within a major version.
I disagree. If the client declares support for it, I think we can very reasonably return new stuff. If we take what we have today in v2 and call that 2, then we could make novaclient send this header: Accept: application/json;version=2 Then, we have a common method in the api code called get_client_version(req), which returns 2 if it's missing, otherwise it returns the version the client declared. When we want to return something new, we do so only if get_client_version(req) >= 3. I think that if we did that, we could support tasks in v2, properly, today. If we _have_ to deprecate something (with the same care, concern, and delay as we've previously proposed deprecating v2 in general) we can return a proper HTTP status code if the client declares a crufty version (or no version at all). The nice thing about that, is that we don't have to deprecate all of v2 just to deprecate something we don't feel we can support anymore for some good technical reason. When we come along and decide that the API should really be organized totally differently than it is today, such that a total rewrite makes sense, we can do that and call it v3. However, for the level of change that we've currently done in v3, I think the above would work just fine and avoid the churn. --Dan _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev