> 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.


OpenStack-dev mailing list

Reply via email to