<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div> </div>
<div> </div>
<div> </div>
<div>On Tue, Feb 16, 2016, at 07:54 AM, Alex Xu wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div> </div>
<div><div> </div>
<div><div>2016-02-16 19:53 GMT+08:00 Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net">sean@dague.net</a>></span>:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div><span>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">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.</div>
<div> </div>
<div>
We specifically stated many times that microversions aren't semver. Each<br></div>
<div>
version is just that.<br></div>
<div> </div>
<div>
Semver only makes sense when you are always talking to one installation,<br></div>
<div>
and the version numbers can only increase. When your code retargets to<br></div>
<div>
multiple installations version numbers can very easily go backwards. So<br></div>
<div>
unless a change in compatible forward and backwards, it's a breaking<br></div>
<div>
change for someone.<br></div>
</blockquote><div> </div>
<div>indeed, learned this point.<br></div>
</div>
</div>
</div>
</blockquote><div> </div>
<div>Fair enough, I wasn't thinking a lot about moving between installations just that we've hidden information within one installation. <br></div>
<div> </div>
<div>Since any change except one that is backwards and forwards compatible is a breaking change for users of multiple clouds what is essentially being said is that we have a new API with every microversion. Given that I wonder if we shouldn't make a stronger statement that the API differs, as in why even have a 2. prefix which implies that 2.x has some relation to 2.x+1 when it doesn't.</div>
<div> </div>
<div>It was mentioned elsewhere in the thread that we have a hard time knowing what's going to end up being compatible or not before it's released. This seems like something we should be able to determine and indicate somehow, even just through docs, otherwise we're passing that burden on to users to determine for themselves.<br></div>
<div> </div>
<div>I very much like that microversions have enabled development to move forward on the API without the mess of extensions that we had previously. I fear that we have no real measurement of the cost of consuming the API under this new scheme. It's easy enough to think that users will just read the docs and carefully consider every version increment that they want to consume but when they've been on version 2.7 for a while and a new thing comes out in 2.35 that they want they need to fully digest the implications of all 27 intervening versions purely through docs and with the understanding that literally almost anything about the semantics can have changed. So while I love the freedom that it provides to developers I think it would be useful to have a small set of constraints in place that helps users. Of course all of my ideas have been duds so far and perhaps that's because I'm imagining future scenarios that won't come to pass or that we don't care about. But something has me concerned and I can't quite get my finger on it.</div>
<div> </div>
<div> </div>
<blockquote type="cite"><div dir="ltr"><div><div><div> </div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div><span><span class="colour" style="color:rgb(136, 136, 136)"><br>
        -Sean<br> <br>
--<br>
Sean Dague<br> <a href="http://dague.net">http://dague.net</a><br></span></span></div>
<div><div><div> </div>
<div>
__________________________________________________________________________<br></div>
<div>
OpenStack Development Mailing List (not for usage questions)<br></div>
<div>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div>
<div> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</div>
</div>
</blockquote></div>
</div>
</div>
<div><u>__________________________________________________________________________</u><br></div>
<div>OpenStack Development Mailing List (not for usage questions)<br></div>
<div>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></div>
<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>
</blockquote><div> </div>
</body>
</html>