Open Stack

During the Kilo design summit session on Oslo versioning changes, we
mostly resolved to switch to semver without alphas and pin stable
branch libs to less than the next nontrivial version number
(allowing for backports to fix bugs with subsequent point releases
on a stable branch when needed). This however raises a question for
other library dependencies, including dependencies on client
libraries.

Specifically, if we're going to limit the Oslo libraries consumed by
stable branches of integrated release servers (bear in mind we
already do this in one way by declaring they can't suddenly start
requiring new dependencies), then how does that play out when we
allow client libraries which are also dependencies of our stable
release servers to depend on later versions of (or for that matter
additional) Oslo libs?

It seems likely we need to apply a similar versioning and branching
model across our client libraries to address this, but this raises
the end-user/app-dev interoperability concern we discuss from time
to time: with a recent enough client library, you should be able to
interact with multiple OpenStack deployments made from different
integrated releases (or non-releases, continuous deployment, et al).

The challenge, then, is to test interactions using our client
libraries under development against older stable servers while
installing those stable servers using different, older versions of
the same client libraries. Perhaps something similar to how
devstack+tempest jobs install devstack/server requirements globally
on the system but then tempest requirements are installed separately
into a virtualenv?
-- 
Jeremy Stanley