<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-02-16 19:53 GMT+08:00 Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/12/2016 03:55 PM, Andrew Laski wrote:<br>
> 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>
</span>Please no.<br>
<br>
We specifically stated many times that microversions aren't semver. Each<br>
version is just that.<br>
<br>
Semver only makes sense when you are always talking to one installation,<br>
and the version numbers can only increase. When your code retargets to<br>
multiple installations version numbers can very easily go backwards. So<br>
unless a change in compatible forward and backwards, it's a breaking<br>
change for someone.<br></blockquote><div><br></div><div>indeed, learned this point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
</font></span><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>