[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