<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 16/02/2016 04:09, Alex Xu a écrit :<br>
</div>
<blockquote
cite="mid:CAH7mGauM=23-OX9JbQNoMjqppEoL8XKrV9Nt9iqx6ivoH5fSVg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-02-16 9:47 GMT+08:00 GHANSHYAM
MANN <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ghanshyammann@gmail.com" target="_blank">ghanshyammann@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Regards<br>
Ghanshyam Mann<br>
<span class=""><br>
<br>
On Mon, Feb 15, 2016 at 12:07 PM, Alex Xu <<a
moz-do-not-send="true" href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>>
wrote:<br>
> If we support 2.x.y, when we bump 'x' is a problem.
We didn't order the API<br>
> changes for now, the version of API change is just
based on the order of<br>
> patch merge. For support 2.x.y, we need bump 'y'
first for back-compatible<br>
> changes I guess.<br>
><br>
> As I remember, we said before, the new feature is
the motivation of user<br>
> upgrade their client to support new version API,
whatever the new version is<br>
> backward compatible or incompatible. So I guess the
initial thinking we hope<br>
> user always upgrade their code than always stop at
old version? If we bump<br>
> 'x' after a lot of 'y', will that lead to user
always stop at 'x' version?<br>
> And the evolution of api will slow down.<br>
><br>
> Or we limit to each release cycle. In each release,
we bump 'y' first, and<br>
> then bump 'x'. Even there isn't any
back-incompatible change in the release.<br>
> We still bump 'x' when released. Then we can
encourage user upgrade their<br>
> code. But I still think the back-incompatible API
change will be slow down<br>
> in development, as it need always merged after
back-compatible API change<br>
> patches.<br>
<br>
</span>Yea that true and will be more complicated from
development<br>
perspective which leads to slow down the evolution of API
changes.<br>
But if we support x.y then still we can change x at any
time back<br>
in-comp changes happens(i mean before y also)? Or I may
not be getting<br>
the issue you mentioned about always bump y before x.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I like the idea of distinguish the backward comp and
in-comp changes<br>
with x and y which always gives clear perspective about
changes.<br>
But it should not lead users to ignore y. I mean some
backward comp<br>
changes which are really good gets ignored by users as
they start look<br>
at the x only.<br>
For example- "adding attribute in resource representation"
is back<br>
comp change (if so) and if that is added as y then, it
might get<br>
ignored by users.<br>
<br>
Another way to clearly distinguish backward comp and
in-comp changes<br>
is through documentation which was initially discussed
during<br>
microversion specs. Currently doc has good description
about each<br>
changes but not much clear way about backward comp or not.<br>
Which we can do by adding a clear flag [Backward
Compatible/<br>
Incompatible] for each version in doc [1]-<br>
<div>
<div class="h5"><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>+1 for doc the change is backward comp or not.</div>
</div>
</div>
</div>
</blockquote>
<br>
I'm not usually good at thinking API references, but something
pinged my brain so lemme know if that's terrible or not.<br>
Why not semantically say that :<br>
- if the API microversion is a ten, then it's a non-backwards
compatible change<br>
- if not, it's backwards-compatible<br>
<br>
If you are like with the version #29 and add a new
backwards-compatible version, then it would be #31 (and not #30).<br>
<br>
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).<br>
<br>
Call me dumb, it's just a thought.<br>
-Sylvain<br>
<br>
<blockquote
cite="mid:CAH7mGauM=23-OX9JbQNoMjqppEoL8XKrV9Nt9iqx6ivoH5fSVg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
><br>
><br>
><br>
> 2016-02-13 4:55 GMT+08:00 Andrew Laski <<a
moz-do-not-send="true"
href="mailto:andrew@lascii.com">andrew@lascii.com</a>>:<br>
>><br>
>> Starting a new thread to continue a thought
that came up in<br>
>><br>
>> <a moz-do-not-send="true"
href="http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html"
rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-February/086457.html</a>.<br>
>> The Nova API microversion framework allows
for backwards compatible and<br>
>> backwards incompatible changes but there is
no way to programmatically<br>
>> distinguish the two. This means that as a
user of the API I need to<br>
>> understand every change between the version
I'm using now and a new<br>
>> version I would like to move to in case an
intermediate version changes<br>
>> default behaviors or removes something I'm
currently using.<br>
>><br>
>> I would suggest that a more user friendly
approach would be to<br>
>> distinguish the two types of changes. Perhaps
something like 2.x.y where<br>
>> x is bumped for a backwards incompatible
change and y is still<br>
>> monotonically increasing regardless of bumps
to x. So if the current<br>
>> version is 2.2.7 a new backwards compatible
change would bump to 2.2.8<br>
>> or a new backwards incompatible change would
bump to 2.3.8. As a user<br>
>> this would allow me to fairly freely bump the
version I'm consuming<br>
>> until x changes at which point I need to take
more care in moving to a<br>
>> new version.<br>
>><br>
>> Just wanted to throw the idea out to get some
feedback. Or perhaps this<br>
>> was already discussed and dismissed when
microversions were added and I<br>
>> just missed it.<br>
>><br>
>>
__________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for
usage questions)<br>
>> Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage
questions)<br>
> Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
</div>
</div>
[1] <a moz-do-not-send="true"
href="https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst"
rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst</a><br>
<div class="HOEnZb">
<div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>