Open Stack

I could use some more clarification on what you would like to see. What do you mean by "recent versions"? How long should a minor version of the OS API be supported in future releases? Should we even expose minor versions as separate endpoints?
 
Personally, I do not feel it necessary to expose minor versions with the understanding that they do not break backwards compatibility. Currently OS API v1.0 and v1.1 may seem like minor versions of the same spec, but they are actually major versions masquerading as such. This fact makes it difficult to support both versions given the current codebase. Really, we should define these as v1 and v2, and develop them side-by-side within the current nova/api/ directory (while sharing as much common code as possible).
 
Waldon
 
-----Original Message-----
From: "Thierry Carrez" <thierry at openstack.org>
Sent: Thursday, March 3, 2011 10:05am
To: openstack at lists.launchpad.net
Subject: Re: [Openstack] Multiple Versions in Openstack API



Brian Waldon wrote:
> Currently, the Openstack API includes a Versions WSGI application. The
> intended purpose is to detail all versions of the API that are reachable
> by a client. Currently, it only supports "v1.0." As we move towards the
> Cactus release, we need to add support for the new "v1.1" specification.
> The intention of the Versions app seems to be to deploy multiple
> versions of the OS API within the same codebase. Since these two
> versions have significant differences, having to support each in the
> same code seems unnatural.
> 
> With the existing approach, versioning could be accomplished multiple
> ways: version-specific "if" statements, version-specific class
> hierarchies, etc. I feel this is inelegant and could be accomplished a
> much cleaner way. I propose we move the responsibilities of the Versions
> app out of the nova codebase and into the hands of the operator of the
> api endpoints. With this approach, the code would not unnecessarily
> increase in complexity as more versions of the api are released. The
> major drawback of this strategy is that each release of Openstack
> Compute could support a single OS API version.

For the OpenStack API to grow a significant partner ecosystem, it seems
important to me to support at least the recent versions of the API in
new releases of Openstack Compute...

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110303/abc266aa/attachment.html>