<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-04 23:27 GMT+08:00 Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Ruby,<br>
<br>
Thanks for starting this thread, just like you I've been always<br>
confused about when and when not bump the microversioning of the API.<br>
<span class=""><br>
> Backwards compatible API adds with no user signaling is a fallacy<br>
> because it assumes the arrow of time flows only one way.<br>
><br>
> If at version 1.5 you have a resource that is<br>
><br>
> foo {<br>
>   "bar": ...<br>
> }<br>
><br>
> And then you decide you want to add another attribute<br>
><br>
> foo {<br>
>   "bar": ...<br>
>   "baz": ...<br>
> }<br>
><br>
> And you don't bump the version, you'll get a set of users that use a<br>
> cloud with baz, and incorrectly assume that version 1.5 of the API means<br>
> that baz will always be there. Except, there are lots of clouds out<br>
> there, including ones that might be at the code commit before it was<br>
> added. Because there are lots of deploys in the world, your users can<br>
> effectively go back in time.<br>
><br>
> So now your API definition for version 1.5 is:<br>
><br>
> "foo, may or may not contain baz, and there is no way of you knowing if<br>
> it will until you try. good luck."<br>
><br>
> Which is pretty aweful.<br>
><br>
<br>
</span>Oh, that's a good point, I can see the value on that.<br>
<br>
Perhaps the guide should define bumping the micro version something<br>
along these words: "Whenever a change is made to the API which is<br>
visible to the client the micro version should be incremented" ?<br></blockquote><div><br></div><div>Yes, I should put some words about why we should bump for back-compatible changes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is powerful because gives the clients a fine grained way to<br>
detect what are the API features available.<br>
<br>
Cheers,<br>
Lucas<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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>