Open Stack

Le 16/02/2016 04:09, Alex Xu a écrit :
>
>
> 2016-02-16 9:47 GMT+08:00 GHANSHYAM MANN <ghanshyammann at gmail.com 
> <mailto:ghanshyammann at gmail.com>>:
>
>     Regards
>     Ghanshyam Mann
>
>
>     On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu <soulxu at gmail.com
>     <mailto: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.

I'm not usually good at thinking API references, but something pinged my 
brain so lemme know if that's terrible or not.
Why not semantically say that :
  - if the API microversion is a ten, then it's a non-backwards 
compatible change
  - if not, it's backwards-compatible

If you are like with the version #29 and add a new backwards-compatible 
version, then it would be #31 (and not #30).

That way, you would still have a monotonic increase, which I think was 
an agreement when discussing about microversioning, but it would help 
the users which would know the semantics and just look whether a ten is 
between the version they use and the version they want (and if so, if it 
was implemented).

Call me dumb, it's just a thought.
-Sylvain

>     >
>     >
>     >
>     > 2016-02-13 4:55 GMT+08:00 Andrew Laski <andrew at lascii.com
>     <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160216/a5db7302/attachment.html>