On 02/26/2014 04:50 PM, Dan Smith wrote:
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.
As I see it, you're not actually disagreeing with using a major version
bump to deal with backwards incompatible changes.
What you're really suggesting is having the client explicitly send
version support in a header, and if they don't then we would assume
version 2.
I don't see how this is fundamentally different than a scheme where the
path has "v3" in it instead of "v2". The two are essentially
equivalent, either way the client indicates which version it supports.
Chris
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
