On 02/24/2014 05:01 PM, Morgan Fainberg wrote: > On the topic of backwards incompatible changes: > > I strongly believe that breaking current clients that use the APIs > directly is the worst option possible. All the arguments about needing > to know which APIs work based upon which backend drivers are used are > all valid, but making an API incompatible change when we’ve made the > contract that the current API will be stable is a very bad approach. > Breaking current clients isn’t just breaking “novaclient", it would also > break any customers that are developing directly against the API. In the > case of cloud deployments with real-world production loads on them (and > custom development around the APIs) upgrading between major versions is > already difficult to orchestrate (timing, approvals, etc), if we add in > the need to re-work large swaths of code due to API changes, it will > become even more onerous and perhaps drive deployers to forego the > upgrades in lieu of stability. > > If the perception is that we don’t have stable APIs (especially when we > are ostensibly versioning them), driving adoption of OpenStack becomes > significantly more difficult. Difficulty in driving further adoption > would be a big negative to both the project and the community. > > TL;DR, “don’t break the contract”. If we are seriously making > incompatible changes (and we will be regardless of the direction) the > only reasonable option is a new major version.
FWIW, I do *not* consider non backwards compatible changes to be on the table for the existing API. Evolving it would have to be done in a backwards compatible way. I'm completely in agreement with that. -- Russell Bryant _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
