<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 1: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"><div class="im">On 22 November 2013 22:31, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>

> Robert Collins wrote:<br>
>> I don't understand why branches would be needed here *if* the breaking<br>
>> changes don't impact any supported release of OpenStack.<br>
><br>
> Right -- the trick is what does "supported" mean in that case.<br>
><br>
> When the client libraries were first established as separate<br>
> deliverables, they came up with a blanket statement that the latest<br>
> version could always be used with *any* version of openstack you may<br>
> have. The idea being, if some public cloud was still stuck in pre-diablo<br>
> times, you could still use the same library to address both this public<br>
> cloud and the one which was 2 weeks behind Havana HEAD.<br>
<br>
</div>Huh. There are two different directions we use the client in.<br>
<br>
Client install -> cloud API (of arbitrary version A)<br>
<br>
Server install (of arbitrary version B) using the Python library -><br>
cloud API (version B)<br>
<br>
>From a gating perspective I think we want to check<br>
that:<br>
 - we can use the client against some set of cloud versions A<br>
 - that some set of version B where servers running cloud version B<br>
can use the client against cloud version B<br>
<br>
But today we don't test against ancient versions of A or B.<br>
<br>
If we were to add tests for such scenarios, I'd strongly argue that we<br>
only add then for case A. Where we are using the client lib in an<br>
installed cloud, we don't need to test that it can still be used<br>
against pre-diablo etc: such installed clouds can keep using the old<br>
client lib.<br></blockquote><div><br></div><div>I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes?</div>
<div><br></div><div>FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So assuming you agree with that assertion, where do we need a branch here?<br>
<div class="im HOEnZb"><br>
-Rob<br>
<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>