Open Stack

On 02/27/2014 08:43 AM, Dan Smith wrote:
>> So I think once we start returning different response codes, or
>> completely different structures (such as the tasks change will be), it
>> doesn't matter if we make the change in effect by invoking /v2 prefix
>> or /v3 prefix or we look for a header. Its a major api revision. I
>> don't think we should pretend otherwise.
>
> I think you're missing my point. The current /v2 and /v3 versions are
> about 10,000 revisions apart. I'm saying we have the client declare
> support for a new version every time we need to add something new, not
> to say that they support what we currently have as /v3. So it would be
> something like:
>
>   version=v2: Current thing
>   version=v3: added simple task return for server create
>   version=v4: added the event extension
>   version=v5: added a new event for cinder to the event extension
>   version=v6: changed 200 to 202 for three volumes calls
>   ...etc

Sure, but that's still functionally equivalent to using the /v2 prefix. 
  So we could chuck the current /v3 code and do:

/v2: Current thing
/v3: invalid, not supported
/v4: added simple task return for server create
/v5: added the event extension
/v6: added a new event for cinder to the event extension

and it would be equivalent.

And arguably, anything that is a pure "add" could get away with either a 
minor version or not touching the version at all.  Only "remove" or 
"modify" should have the potential to break a properly-written application.

Chris