On Tue, Jun 19, 2012 at 11:07:05AM -0700, Monty Taylor wrote: > I'm going to top-post, because there is a whole other thing which is not > a response to points below. Basically, this is yet-another-instance of > two competing and partially contradictory sets of use cases and usage > patterns that we're trying to find the right compromise for. > > Tying client libs to server releases is really handy for the distros. It > is terrible for the public cloud implementations who are doing rolling > releases - not in as much as it effects the public cloud's ability to > use the client libs - they can obviously pull trunk client lib from git > and use that for intra-server communication just fine as part of their > deployment. Rather, it is a terrible experience for the end-users of > OpenStack public clouds.
With my distro hat on, I don't actually think tying client libs to server releases is a particularly big factor. What the absolutely critical factor is for distros, particularly enterprise distros, is that /any/ client lib release be capable of talking to /any/ server release. Mandating matched versions of (client,sever) is a really undesirable because it is inevitable that at some point deployments will end up with a mix of openstack server releases. So if the client libs are on a more frequent release cycle than the server releases, that is fine from a distro POV. Though I'd expect you'd want the client libs release cycle to allow for it to periodically line with the major server releases for convenience. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp