<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I can't make the meeting today but I would have wanted to discuss <br>
<br>
Step four make sure tempest has adequate tests to detect
incompatible changes in client python apis. I think this would
require two steps:<br>
<br>
1. Make sure we have good coverage of the client apis, perhaps by
making sure the scenario tests cover widely<br>
2. Run the scenario tests of previous api versions using clients
from master<br>
<br>
This is kind of tricky.<br>
<br>
-David<br>
<div class="moz-forward-container"><br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject:
</th>
<td>Re: [openstack-dev] The danger of capping
python-*clients in core projects, and forbidding it in the
future</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Thu, 11 Jul 2013 06:38:26 -0400</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Sean Dague <a class="moz-txt-link-rfc2396E" href="mailto:sean@dague.net"><sean@dague.net></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Reply-To:
</th>
<td>OpenStack Development Mailing List
<a class="moz-txt-link-rfc2396E" href="mailto:openstack-dev@lists.openstack.org"><openstack-dev@lists.openstack.org></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>On 07/11/2013 05:06 AM, Thierry Carrez wrote:
> Sean Dague wrote:
>> I think we need to get strict on projects and prevent them from capping
>> their client requirements. That will also put burden on clients that
>> they don't break backwards compatibility (which I think was a goal
>> regardless).
>
> Indeed. The whole idea behind a single release channel for python client
> libraries was that you should always be running the latest, as they
> should drastically enforce backward compatibility.
>
> Any reason why those caps were introduced in the first place ?
Well global requirements specifies caps for most clients:
python-cinderclient>=1.0.4,<2
python-ceilometerclient>=1.0.1
python-heatclient>=0.2.2
python-glanceclient>=0.9.0,<2
python-keystoneclient>=0.2.1,<0.4
python-memcached
python-neutronclient>=2.2.3,<3.0.0
python-novaclient>=2.12.0,<3
python-quantumclient>=2.2.0,<3.0.0
python-swiftclient>=1.2,<2
I assume projects just copied those lines into their requirements. Then
keystoneclient bumped release number, and got outside the boundary that
was allowed by some project.
I know a flury of python-keystoneclient patches went in after
python-keystoneclient 0.3.0 released, but has a broken compatibility issue.
So step one is purge from global requirements.
Step two purge from projects.
Step three enforce they don't come back.
-Sean
--
Sean Dague
<a class="moz-txt-link-freetext" href="http://dague.net">http://dague.net</a>
_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
<br>
</div>
<br>
</body>
</html>