[openstack-dev] [sahara] summit wrap-up: backward compat

Trevor McKay tmckay at redhat.com
Thu May 29 13:54:38 UTC 2014


Catching up...

On Thu, 2014-05-29 at 15:59 +0400, Alexander Ignatov wrote:
> On 28 May 2014, at 17:14, Sergey Lukjanov <slukjanov at mirantis.com> wrote:
> > 1. How should we handle addition of new functionality to the API,
> > should we bump minor version and just add new endpoints?
> 
> Agree with most of folks. No new versions on adding new endpoints. 
> Semantic changes require new major version of rest api.

+1 this and previous comments.  I don't think we'll generate too many
semantic changes (but I could be wrong :) )

I agree with Mike that we should have simple version numbers, v1, v2, v3

> > 2. For which period of time should we keep deprecated API and client for it?
> 
> One release cycle for deprecation period.

+1.  If we give folks N cycles, they will always wait until the Nth
cycle to move away.  Might as well be 1.

> 
> > 3. How to publish all images and/or keep stability of building images
> > for plugins?
> > 
> 
> We should keep all images for all plugins (non-deprecated as Matt mentioned) 
> for each release. In addition we could keep  at least one image which could be 
> downloaded and used with master branch of Sahara. Plugin vendors could keep 
> its own set of images and we can reflect it in the docs.

I agree with keeping all images grouped with a release for all supported
plugins in that release.

Are we suggesting here that there are 2 places to find images, one in
the Sahara releases and a second in a vendor repo listed in the docs?

> Regards,
> Alexander Ignatov
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





More information about the OpenStack-dev mailing list