Open Stack

There was a summit session on using a common dependency list and I think
the consensus there was to remove the upper bounds on dependencies where
possible (eg not sqlalchemy where version 0.8 breaks the current projects).
Then, when stable branches for releases are cut, the dependencies for those
projects would have upper bounds added for the currently available versions
(the versions of dependencies that the gate will be testing against at that
time). That way changes in upstream don't break the stable branches. Might
be worth running this by markmc and/or mordred to make sure I am
remembering correctly.

Also, the above decisions were made assuming there would be a common
dependency list across openstack projects. Perhaps we should put more
resources behind that effort to reduce the occurrence of these odd
dependency problems.

Clark

On Tue, Dec 4, 2012 at 4:43 PM, Henry Nash <henryn at linux.vnet.ibm.com>wrote:

> Hi
>
> Openstack projects use pip-requires to indicate their dependencies.  While
> most of these dependencies are external components, some are other
> openstack projects - the classic example is that any project that will use
> keystone to authenticate obviously has a dependency on it.  Until recently
> this was usually specified in the pip-requries as:
>
> python-keystoneclient>=0.1,<0.2
>
> This recently broke when we incremented the keystoneclient version to 0.2
> (which also included the move of the authentication code into the client
> from the server - making the dependency on the client particularly
> relevant).
>
> I was in the process of updating any such dependencies (see:
> https://review.openstack.org/#/c/16375/), when I discovered that it
> appears there are differing views on whether we should have an upper limit
> to the version dependency, i.e. should we change this to:
>
> python-keystoneclient>=0.2,<0.3 (or maybe even 1.0)
>
> or maybe just
>
> python-keystoneclient>=0.2
>
> I must admit, I question the use of the upper limit - given that we don't
> have any plans to cut off support.  I assume the rationale of defining one
> before was to give us the option of such a cut off?  Can anyone confirm
> that?
>
> I'd like to canvas views on whether there should be an upper limit - that
> isn't the standard everywhere (although we have done it for keystone to
> date).  My gut feel is to remove the upper limit - but am open to
> persuasion :-)
>
> Henry
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121204/20ca853f/attachment.html>