Open Stack

Le 16/02/2016 09:30, Sylvain Bauza a écrit :
>
>
> 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
>

One slight improvement could be to consider hundreds and not tens for 
major versions. That would leave 99 'minor' versions between majors, 
which I think is doable.

-S

>>     >
>>     >
>>     >
>>     > 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
>
>
>
> __________________________________________________________________________
> 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/24965faa/attachment.html>