[libvirt] Drop support for old libvirt versions?

[Daniel P. Berrange]

On Sat, Aug 13, 2016 at 02:03:39PM -0400, Laine Stump wrote:
> On 08/13/2016 09:24 AM, Martin Kletzander wrote:
> > On Sat, Aug 13, 2016 at 10:16:03AM +0200, Michal Privoznik wrote:
> > > On 12.08.2016 18:25, Andrea Bolognani wrote:
> > > > <snip/>
> > > > 
> > > 
> > > I like the idea. I mean, the less versions we have to take care of the
> > > better. But before we go any further - what do you mean by dropping
> > > support? For instance, what I think of is when formatting migration XML
> > > we won't remove devices (like USB hubs or what is it) just because the
> > > other side is too old.
> > > 
> > > Or you even mean deprecating APIs?
> > > 
> > 
> > My question exactly.  What support are you talking about?  Forward
> > compatible migration support (migrating back to older libvirt versions)?
> > I don't think that's very much supported at all.  Talking about old APIs
> > (e.g. superseded and obsoleted ones)?  I don't think we can do that.
> 
> Correct. In order to remove anything from the API, we would need to
> increment the shared library .so version, which libvirt has promised to
> never do. We can only ever add to APIs (and XML).
> 
> 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.

> 2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older
> than the support cutoff.

Well we already don't officially do releases to all old maint branches, and
we've never guaranteed we'll backport CVE to all old maint branches. Typically
I'll backport the patches far as they'll cherry pick easily and perhaps do a
few manual fixes. When the backport starts getting "hard" though I'll stop
and leave the branch unfixed.

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 :|