Yep, I think we're in agreement. Version 1 should always be backwards compatible. Once we need to make a backwards incompatible change, we need to talk about version 2.
Waldon On Oct 10, 2011, at 2:11 PM, George Reese wrote: > 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 > > 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
