On Mon, 2016-08-15 at 09:39 +0100, Daniel P. Berrange wrote: > > My interpretation was that Andrea is suggesting two things: > > > > 1) remove any code within libvirt that maintains compatibility when a > > contemporary libvirtd (or application using contemporary libvirt client > > library) is communicating with a version of libvirtd older than the support > > cutoff. This would include things like removing certain XML during > > migration, and (in virsh) falling back to an older deprecated API when a > > newer API isn't available (e.g. falling back to virDomainDefineXML() when > > virDomainDefineXMLFlags() isn't available). > > I'm not in favour of dropping the virsh compat support - IMHO it is pretty > beneficial and not really a significant maint burden to deal with it. > > The migration compat doesn't seem like a particularly significnt burden > either to be honest. This is quite different from the QEMU code where > our command line generator has huge amounts of complexity for dealing > with different QEMU syntaxes, particularly around the -device introduction. It's not necessarily a huge burden; that said, I believe there's some value in having a well-defined and explicit cut-off point for libvirt versions like we already have for qemu versions, especially when such a cut-off point is defined against a moving target (eg. "libvirt and qemu versions shipped in supported Linux distributions"). That's not to say we should necessarily go through the code with a fine-toothed comb and get rid of all compatibility stuff right away; however, if your changes are at odds with some code that's kinda hacky and its only purpose is to support migration to libvirt versions that are hardly relevant anymore, I think it would be better to drop the compatibility code rather than waste time updating it. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list