openstack-poc team mailing list archive
-
openstack-poc team
-
Mailing list archive
-
Message #00240
Re: API compatibility
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 <jaypipes@xxxxxxxxx> wrote:
> On Wed, Sep 7, 2011 at 3:58 AM, Ewan Mellor <Ewan.Mellor@xxxxxxxxxxxxx>
> 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 : openstack-poc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References