<div dir="ltr">This was a good session lead by Robert to fully understand the repercussions of not ensuring backward compatibility guidelines.<div><br></div><div>In layman's terms, an Oslo API change made in Mitaka (the last release) must remain fully backward compatible throughout the entire Newton release (the current release). </div><div>A great reason is for all other OpenStack projects that do/may use and adopt any Oslo changes from Mitaka.  </div><div>If Oslo DID NOT maintain backwards compatibility throughout the full length of the next cycle, then projects that had either implemented or plan to implement Mitaka Oslo features may then have failing gate tests during this cycle causing rework. </div><div>Oslo needs to remain stable during an entire cycle to ensure projects can work consistently with Oslo libraries.  <br><div><br></div><div>Thanks to Angus Lees (Gus) who in true debate form took the side of nay to validate the proposal and enable a clear discussion (in the second of last session).</div></div><div><br></div><div>Ronald</div><div><br></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div style="font-family:arial;font-size:small"><br></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Apr 29, 2016 at 2:13 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yesterday, in <a href="https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing</a><br>
we actually reached consensus - well, 7/10 for and noone against -<br>
doing 1 cycle backwards compatibility in Oslo.<br>
<br>
That means that after we release a thing, code using it must not break<br>
(due to an Oslo change) until a release from the cycle *after* the<br>
next cycle..<br>
<br>
Concretely, add a thing at the start of L, we can break code using<br>
that exact API etc at the start of N. We could try to be clever and<br>
say 'Release of L, can break at the start of N', but 'release of L' is<br>
now much fuzzier than it used to be - particularly with independent<br>
releases of some things. So I'd rather have a really simple easy to<br>
define and grep for rule than try to optimise the window. Happy if<br>
someone else can come up with a way to optimise it.<br>
<br>
This is obviously not binding on any non-oslo projects: os-brick,<br>
python-neutronclient etc etc: though I believe folks in such projects<br>
are generally cautious as well.<br>
<br>
The key thing here is that we already have to do backwards compat to<br>
move folk off of a poor API onto a new one: all this policy says is<br>
that the grace period needs to cross release boundaries.<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hpe.com">rbtcollins@hpe.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<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>
</font></span></blockquote></div><br></div></div>