<div dir="ltr">I don't know if this is really a big problem. IMO, even with microversions you shouldn't be implementing things that aren't backwards compatible within the major version. I thought the benefit of microversions is to know if a given feature exists within the major version you are using. I would consider a breaking change to be a major version bump. If we only do a microversion bump for a backwards incompatible change then we are just using microversions as major versions.<div><br></div><div>-Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 28, 2015 at 3:45 AM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/28/2015 09:34 AM, Valeriy Ponomaryov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dmitriy,<br>
<br>
New tests, that cover new functionality already know which API version<br>
they require. So, even in testing, it is not needed. All other existing<br>
tests do not require API update.<br>
</blockquote>
<br></span>
Yeah, but you can't be sure that your change does not break the world, until you merge it and start updating tests. Probably it's not that important for projects who have their integration tests in-tree though..<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
So, I raise hand for restricting "latest".<br>
<br>
On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur <<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a><br></span><div><div class="h5">
<mailto:<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>>> wrote:<br>
<br>
    On 08/27/2015 09:38 PM, Ben Swartzlander wrote:<br>
<br>
        Manila recently implemented microversions, copying the<br>
        implementation<br>
        from Nova. I really like the feature! However I noticed that<br>
        it's legal<br>
        for clients to transmit "latest" instead of a real version number.<br>
<br>
        THIS IS A TERRIBLE IDEA!<br>
<br>
        I recommend removing support for "latest" and forcing clients to<br>
        request<br>
        a specific version (or accept the default).<br>
<br>
<br>
    I think "latest" is needed for integration testing. Otherwise you<br>
    have to update your tests each time new version is introduced.<br>
<br>
<br>
<br>
        Allowing clients to request the "latest" microversion guarantees<br>
        undefined (and likely broken) behavior* in every situation where a<br>
        client talks to a server that is newer than it.<br>
<br>
        Every client can only understand past and present API<br>
        implementation,<br>
        not future implementations. Transmitting "latest" implies an<br>
        assumption<br>
        that the future is not so different from the present. This<br>
        assumption<br>
        about future behavior is precisely what we don't want clients to<br>
        make,<br>
        because it prevents forward progress. One of the main reasons<br>
        microversions is a valuable feature is because it allows forward<br>
        progress by letting us make major changes without breaking old<br>
        clients.<br>
<br>
        If clients are allowed to assume that nothing will change too<br>
        much in<br>
        the future (which is what asking for "latest" implies) then the<br>
        server<br>
        will be right back in the situation it was trying to get out of<br>
        -- it<br>
        can never change any API in a way that might break old clients.<br>
<br>
        I can think of no situation where transmitting "latest" is<br>
        better than<br>
        transmitting the highest version that existed at the time the<br>
        client was<br>
        written.<br>
<br>
        -Ben Swartzlander<br>
<br>
        * Undefined/broken behavior unless the server restricts itself<br>
        to never<br>
        making any backward-compatiblity-breaking change of any kind.<br>
<br>
<br>
        __________________________________________________________________________<br>
        OpenStack Development Mailing List (not for usage questions)<br>
        Unsubscribe:<br>
        <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></div></div>
        <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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:<br>
    <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></span>
    <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
--<br>
Kind Regards<br>
Valeriy Ponomaryov<br>
</span><a href="http://www.mirantis.com" rel="noreferrer" target="_blank">www.mirantis.com</a> <<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a>><br>
<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a> <mailto:<a href="mailto:vponomaryov@mirantis.com" target="_blank">vponomaryov@mirantis.com</a>><span class=""><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>
</span></blockquote><div class="HOEnZb"><div class="h5">
<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>
</div></div></blockquote></div><br></div>