<div dir="ltr"><div>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.</div><div><br></div>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.<div><br></div><div><div><div>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.</div><div><div><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-13 4:55 GMT+08:00 Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Starting a new thread to continue a thought that came up in<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>
</blockquote></div><br></div>