Just to clear up some questions I have already gotten: The revision numbers are designed only to advertise additions to the spec, wether they be new fields or whole resources. The revision number does not advance if we make a bug fix within Nova, as the spec itself needs to evolve independently of our implementation.
Waldon On Oct 10, 2011, at 9:55 AM, Brian Waldon wrote: > In talking with several people at the Design Summit about the OpenStack > Compute API, I have come to the conclusion that our current method of > versioning is broken. I would like to propose that as we move forward, we > adopt the following API versioning conventions: > > 1) Use a three-part version number: A.B.C, where A is the major version, B is > the minor version, and C is the revision number. > > 2) Disallow backwards incompatible changes to existing interfaces within a > major version. This means we cannot rename something such as /servers to > /interfaces, or remove the resize action from a server. > > 3) Increment the minor version at OpenStack releases (Cactus, Diablo, Essex, > etc). This is used to indicate the 'regrouping' period around the time of > release. It doesn't offer much functionality other than to provide a nice > round number that can be easily communicated and used to group features > together. > > 4) Increment the revision number with every addition to the API interface. > This allows consumers of the API to get a precise list of supported features > at any given time. This also allows operators to continuously deploy the API > between major releases and know exactly what featureset they have. When the > minor version is increased, we reset the revision number to 0. > > I would assume that if we do agree on these conventions, they would only be a > suggestion, not a requirement. I really want to get this right, so I'm > looking forward to everybody's feedback! > > Thanks! > Brian Waldon > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > This email may include confidential information. If you received it in error, > please delete it. > -------------------------------------- Brian Waldon Cloud Software Developer Rackspace Hosting _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
