Open Stack

2016-02-16 9:47 GMT+08:00 GHANSHYAM MANN <ghanshyammann at gmail.com>:

> Regards
> Ghanshyam Mann
>
>
> On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu <soulxu at 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 <andrew at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/1b85b6cf/attachment.html>