<div class="gmail_quote">On Sat, Jan 26, 2013 at 12:32 AM, Ray Pekowski <span dir="ltr"><<a href="mailto:pekowski@gmail.com" target="_blank">pekowski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>
Otherwise new non-backward compatible changes would need to go through two releases.  The first for the option to be recognized but disabled and a second for it to actually be enable, just as being done for the RPC envelope.  With my proposal, we can skip the recognizing release, since by definition an unknown entry in the envelope is recognized as a failure.<br>
</div></div></blockquote><div><br>Is this two release approach for non-backward compatible RPC protocol changes even acceptable?  The RPC envelope change (<a href="https://blueprints.launchpad.net/oslo/+spec/version-rpc-messages">https://blueprints.launchpad.net/oslo/+spec/version-rpc-messages</a>) is in the first part of this two release approach.  It makes Grizzly RPC aware of envelopes, but does not use them.  I think this approach will limit release migrations to N-1, at least if part of the migration includes coexistence of releases.  Is it true we never plan to migrate from anything older than the previous release?<br>
<br>Once the RPC envelope change hits the H release and it is enabled, without some other change, the H level RPCs will only be able to communicate with Grizzly and greater, not Folsom, not Essex, etc.  I'm just wondering if this is such a good idea.<br>
</div></div>