Open Stack

I'm following these discussions because we're starting to discuss API versioning in Swift. Nothing's been decided in Swift yet, but to share some of my thoughts, in no particular order:

I prefer /capabilities, because this also fits well with important discoverability things in swift like max object size or max object metadata (ie everything defined in https://github.com/openstack/swift/blob/master/etc/swift.conf-sample#L15).

I can't imagine that we'll ever really remove a particular version of the API in Swift. API versioning is a nice way to isolate changes that may break existing clients, but we don't want to drop support for existing clients.

In order to do any sort of API versioning, we'll need to add in API version discoverability into Swift (it doesn't exist because we haven't ever changed our API before). I'd love help (patches) from someone who has worked on API versioning for other OpenStack projects.

--John




On May 2, 2013, at 2:09 PM, Gabriel Hurley <Gabriel.Hurley at nebula.com> wrote:

>> Question: doesn't this go semi-into the stuff Keystone guys are working on for the ServiceCatalog? 
> 
> Yes, it definitely does. In fact, it's revisiting some decisions that were made many releases ago because they didn't allow for everything a complex cloud with multiple API versions or a single consumer that works with multiple clouds with different API versions might need. These use cases have become a reality and it's time to build a system that supports us going forward. :-)
> 
> FWIW, Dolph (Keystone PTL) has weighed in on the subject several times already and we're generally in alignment.
> 
>    - Gabriel
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev