Open Stack

Bunch of responses/thoughts:

> API

I'm ok that semantics additions could be done in one API version w/o
increasing minor version. I like the idea to keep only major API
versions starting from the next API version.
RE backward compat period, for now 1-2 cycles is ok.

> Images

Agreed that we should publish release images for non-deprecated
plugins (somehow, all on infra or vendor-based).

On Thu, May 29, 2014 at 3:59 PM, Alexander Ignatov
<aignatov at mirantis.com> 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.
>
>> 2. For which period of time should we keep deprecated API and client for it?
>
> One release cycle for deprecation period.
>
>> 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.
>
> Regards,
> Alexander Ignatov
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.