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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
