2016-02-16 9:47 GMT+08:00 GHANSHYAM MANN <ghanshyamm...@gmail.com>: > Regards > Ghanshyam Mann > > > On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu <sou...@gmail.com> wrote: > > If we support 2.x.y, when we bump 'x' is a problem. We didn't order the > API > > changes for now, the version of API change is just based on the order of > > patch merge. For support 2.x.y, we need bump 'y' first for > back-compatible > > changes I guess. > > > > As I remember, we said before, the new feature is the motivation of user > > upgrade their client to support new version API, whatever the new > version is > > backward compatible or incompatible. So I guess the initial thinking we > hope > > user always upgrade their code than always stop at old version? If we > bump > > 'x' after a lot of 'y', will that lead to user always stop at 'x' > version? > > And the evolution of api will slow down. > > > > Or we limit to each release cycle. In each release, we bump 'y' first, > and > > then bump 'x'. Even there isn't any back-incompatible change in the > release. > > We still bump 'x' when released. Then we can encourage user upgrade their > > code. But I still think the back-incompatible API change will be slow > down > > in development, as it need always merged after back-compatible API change > > patches. > > Yea that true and will be more complicated from development > perspective which leads to slow down the evolution of API changes. > But if we support x.y then still we can change x at any time back > in-comp changes happens(i mean before y also)? Or I may not be getting > the issue you mentioned about always bump y before x. >
If the back-incompatible change merged before back-compatible change, then 'y' become useless. For example, the initial version is 2.1.0, then we have 3 back-comp and 3 in-comp changes, and we are unlucky, in-comp changes merged first, then we get version 2.4.3, then if user want to use those back-comp changes, it still need upgrade those 3 in-comp changes. > > I like the idea of distinguish the backward comp and in-comp changes > with x and y which always gives clear perspective about changes. > But it should not lead users to ignore y. I mean some backward comp > changes which are really good gets ignored by users as they start look > at the x only. > For example- "adding attribute in resource representation" is back > comp change (if so) and if that is added as y then, it might get > ignored by users. > > Another way to clearly distinguish backward comp and in-comp changes > is through documentation which was initially discussed during > microversion specs. Currently doc has good description about each > changes but not much clear way about backward comp or not. > Which we can do by adding a clear flag [Backward Compatible/ > Incompatible] for each version in doc [1]- > > +1 for doc the change is backward comp or not. > > > > > > > > 2016-02-13 4:55 GMT+08:00 Andrew Laski <and...@lascii.com>: > >> > >> Starting a new thread to continue a thought that came up in > >> > >> > http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html > . > >> The Nova API microversion framework allows for backwards compatible and > >> backwards incompatible changes but there is no way to programmatically > >> distinguish the two. This means that as a user of the API I need to > >> understand every change between the version I'm using now and a new > >> version I would like to move to in case an intermediate version changes > >> default behaviors or removes something I'm currently using. > >> > >> I would suggest that a more user friendly approach would be to > >> distinguish the two types of changes. Perhaps something like 2.x.y where > >> x is bumped for a backwards incompatible change and y is still > >> monotonically increasing regardless of bumps to x. So if the current > >> version is 2.2.7 a new backwards compatible change would bump to 2.2.8 > >> or a new backwards incompatible change would bump to 2.3.8. As a user > >> this would allow me to fairly freely bump the version I'm consuming > >> until x changes at which point I need to take more care in moving to a > >> new version. > >> > >> Just wanted to throw the idea out to get some feedback. Or perhaps this > >> was already discussed and dismissed when microversions were added and I > >> just missed it. > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > [1] > https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
