<div class="gmail_quote">On Mon, Jan 28, 2013 at 1:38 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's pretty much how all of the rpc internal API backwards<br>
compatibility has been handled so far.  We've got versioning on the<br>
APIs, but no real intention to maintain compatibility beyond N-1.  The<br>
code gets messy enough maintaining backwards compatibility just 1<br>
release back.  The eventual goal is to allow rolling upgrades from<br>
release to release.  If you need to go to N+2, you either don't do a<br>
live upgrade or you go through N+1 first.<br></blockquote><div><br>Thank you, I feel better that this has been thought about.  Of course, everything can be improved upon.  This is the second part of my proposal: fail an RPC if the envelope includes foreign keys.  This could be used to add a feature in the release it was conceived, instead of waiting for two releases, as follows:<br>
<ul><li>Release N has a new feature.</li><li>It identifies it's new feature with a new key in the RPC envelope it sends on each request</li><li>When and RPC call is made to an older version, the older version returns a version mismatch error since it does not recognize the foreign key.</li>
<li>The RPC is immediately re-issued in a compatible way, without the foreign key.</li></ul><p>The consequence is downlevel RPCs require two calls so are very inefficient but do suceed.  This does not preclude the two release method.  It just provides more options.</p>
<p>Just a thought<br></p><p>Ray<br></p></div></div>