On Tue, Jul 3, 2012 at 2:59 PM, Gabriel Hurley <gabriel.hur...@nebula.com>wrote:
> The notion that copying code is any protection against APIs that may > change is a red herring. It's the exact same effect as pegging a version of > a dependency (whether it's a commit hash or a real version number), except > now you have code duplication. An unstable upgrade path is an unstable > upgrade path, and copying the code into the project doesn't alleviate the > pain for the project if the upstream library decides to change its APIs. > It does if the API being changed is the one that was copied because it means the project doesn't have to respond to the change immediately. For example, if we add something to the rpc library that ceilometer needs, nova doesn't have to stop what they're doing to handle any potential changes. If openstack-common was installed as a separate library, there wouldn't be a (good) way to have both versions installed so ceilometer and nova couldn't run on the same host (a requirement for the ceilometer agent). So, I'm +1 on turning common into *several* libraries with their own versioning scheme, when the components are ready. I don't see a need to rush that as part of Folsom, though. Doug
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
