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