<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 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 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><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 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 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 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 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 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 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 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 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 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>