<div dir="ltr"><div class="gmail_quote">On Wed, Apr 8, 2015 at 7:38 AM Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 04/07/2015 11:35 PM, Michael Davies wrote:<br>
> I agree with Jim R's suggestion - it's really up to the consumer as to what they<br>
> want to do.  Having said that...<br>
><br>
> I think that any consumer wants to use the latest version of the API that it can<br>
> support.<br>
><br>
> And so since we're not planning on making any breaking API changes[1], I think<br>
> any consumer wants to:<br>
><br>
> a) have a concept of the latest API version that it has been coded for<br>
> b) then, in negotiation with the server, choose a version that suffices:<br>
> b1) negotiated_version = min(your code's max version, max Ironic server version) and<br>
> b2) negotiated_version > your code's supported version<br>
> b3) negotiated_version > Ironic API's minimum version<br>
<br>
Is that statement about "not planning on making any breaking API changes" an<br>
intention or a guarantee?<br>
<br>
The reason I ask is that doc/source/devref/api_<u></u>microversions.rst contains an<br>
explicit mention of making breaking changes:  "So breaking changes can be added<br>
to the API without breaking users who don't specifically ask for it."<br><br></blockquote><div><br></div><div>We will continue to support the same API that we had at the point we introduced microversioning, which can be represented as v1.1, and is inferred when there is no version header in the request. This should be completely compatible with any client built against stable/juno.</div><div><br></div><div>There was a change introduced during Kilo which may break some clients, were they not to upgrade; that change is only exposed when the requested version is >= 1.2. Thus, older clients are not affected (but also do not see new features).</div><div><br></div><div>In versions 1.3 - 1.6, we made several additions that we believed would not break any client expecting v1.2, but incremented the API microversion to indicate those changes. In this way, a newer client could discover what is supported by a server it connects to.</div><div><br></div><div>I have no plans to remove support for v1.1 at this time. The language in the spec lays out the approach we should take, were we ever to find the need to remove support for v1.1. While I hope we never need to, describing it was an important part of the process to arrive at how we implemented microversions.</div><div><br></div><div>-Devananda<br></div></div></div>