[openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future

Sean Dague sean at dague.net
Thu Jul 11 10:38:26 UTC 2013


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
http://dague.net



More information about the OpenStack-dev mailing list