Wouldn't this mean that versions of the API for projects would then have a version that is reflective of the release and not a spec number? Version 1.1 doesn't mean anything in Diablo if it doesn't adhere to the 1.1 guide? The api would be versioned for diablo and we would start a new version for essex?
On Wed, Sep 7, 2011 at 8:34 AM, Jay Pipes <[email protected]> wrote: > On Wed, Sep 7, 2011 at 3:58 AM, Ewan Mellor <[email protected]> > wrote: > > Firstly, apologies for not making the PPB meeting today. I was actually > > locked in a meeting about OpenStack API support, which is ironic given > the > > topic of conversation at the PPB today. > > Ironic indeed :) > > > Obviously the API can continue to evolve – it just needs to do so in a > > backwards-compatible (or versioned) manner. > > Agreed. The thing that was being proposed and agreed upon yesterday was > about: > > a) That PTLs control their project's APIs > b) That the PPB will set some general guidelines for the APIs > c) That a coordinator role should exist to advise PTLs on matters > relating to consistency of the project APIs > > I would be amenable to a diktat (to borrow your term) saying APIs must > be backwards compatible for clients built to a prior release series > API version. > > > Also, extensions would be excluded from this – caveat extensor, or > > something. > > Yup. > > Cheers, > -jay > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack-poc > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack-poc > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack-poc Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
