A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11. Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well. Here's a quick run down of relevant libvirt versions: SLES 11 → ???

RHEL 6.0 → 0.8.1 Ubuntu 12.04 → 0.9.2 RHEL 6.8 → 0.10.2 Ubuntu 12.04.5 → 0.9.8 SLES 11 SP4 → 1.2.5 One thing I'm not clear about is whether or not SUSE, Red Hat and Canonical will support old minor releases or just the latest one.

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?

Michal -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

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). 2) stop maintaining bugfixes (including CVE fixes?) on -maint branches older than the support cutoff. 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).

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).

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

A while ago, we agreed to drop support for QEMU versions older than 0.12.0, with the rationale that we should focus on operating systems that are still supported by the respective vendors, eg. RHEL/CentOS 6, Ubuntu 12.04 and SLES 11. Recently, when discussing how to ensure a certain change will not break migration with libvirt <= 0.9.4, I started wondering whether we should apply the same rationale to libvirt versions as well. Here's a quick run down of relevant libvirt versions:   SLES 11        → ???   RHEL 6.0       → 0.8.1   Ubuntu 12.04   → 0.9.2   RHEL 6.8       → 0.10.2   Ubuntu 12.04.5 → 0.9.8   SLES 11 SP4    → 1.2.5