Open Stack

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