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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
