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 <aigna...@mirantis.com> wrote: > > On 28 May 2014, at 17:14, Sergey Lukjanov <slukja...@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@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
