On Sat, 2016-08-13 at 21:09 +0200, Martin Kletzander 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). > > > > 2) stop maintaining bugfixes (including CVE fixes?) on -maint branches > > older than the support cutoff. I was thinking mostly of the first point :) > > I would vote +1 for doing both of these. If we do, we should document > > somewhere in the source and on the website exactly what is the oldest > > supported version, (and we may want to make a list of current versions > > that are still in use in distros, and a minimum "support end date" for > > them, then revisit it periodically). > > That sounds very reasonable. I'd agree. > > The only thing I'm thinking about how to handle it a bit better, > compared to the QEMU cutoff we did, is how should we handle the code > cleanup and removal so that there is as little leftover as possible. I > think there will be some leftovers stuck forever in both QEMU and > libvirt compatibility related parts. It's just that we should somehow > come up with how to shave it off as cleanly as possible. I'm not sure we really need to get out of our way to weed out existing compatibility code. What I care about is being able to say "we don't support that" when writing new code or reworking existing one. That said, if anyone feels like being a little more proactive I will certainly not the one to stop him! :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list