Open Stack

On Tue, 2012-12-04 at 21:41 -0800, Clark Boylan wrote:
> 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).

Yep, here's the notes from the session:

http://etherpad.openstack.org/process-dependency-management

Upper bounds shouldn't be used except where we know a library has (or
maybe - based on history - is extremely likely to) released a newer
version with an API change that breaks us. Our client libraries
certainly should be doing that.

> 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.

There was some confusion about this - I wanted to pin the gating
infrastructure to specific versions, but didn't want to prevent
users/distros from using stable releases with newer versions of
libraries.

All summarized here:

http://lists.openstack.org/pipermail/openstack-dev/2012-November/002075.html

> 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.

Yes ... Monty and I have been driving a lot of the discussions around
this, but that doesn't mean others can't dive in and actually start
fixing it :-)

IMHO, the first thing is to go through all the pip-requires of our
projects and resolve places where there are conflicting requirements.

Cheers,
Mark.