API implementations should always be backwards compatible. The behavior should be dependent on the client's requested version.
The only thing that should not propagate is bugs. On Oct 10, 2011, at 2:55 PM, 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 -- George Reese - Chief Technology Officer, enStratus e: [email protected] t: @GeorgeReese p: +1.207.956.0217 f: +1.612.338.5041 enStratus: Governance for Public, Private, and Hybrid Clouds - @enStratus - http://www.enstratus.com To schedule a meeting with me: http://tungle.me/GeorgeReese
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
