[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