On Mon, Oct 07, 2019 at 04:58:34PM +0200, Andrea Bolognani wrote: > On Mon, 2019-10-07 at 13:35 +0100, Daniel P. Berrangé wrote: > > On Mon, Oct 07, 2019 at 01:58:10PM +0200, Andrea Bolognani wrote: > > > Can't we follow the same policy as the main library? That would make > > > it more straightforward to reason about. Also note that our CI only > > > runs jobs on the platforms targeted by the main library, which means > > > RHEL 6 and Ubuntu 14.04 are out already... > > > > I don't think this is the same kind of situation at play, because of how > > it interacts with application developers expressing their dependancies > > for the language bindings. If an app expresses a dep on the oldest > > version of libvirt-python they support they can't use APIs newer than > > that. If an app expresses a dep on the newest version of libvirt-python > > they can use, then they can conditionally use the new APIs while still > > being compatible with the older ihnstalls. This works regardless of > > our support policy wrt the main libvirt EOL. > > > > If we put the same EOL policy on the language bindings, we're either > > forcing the application onto the same support policy as libvirt, or > > making their build / deployment process more complicated, neither of > > which I think are reasonable. > > > > With main libvirt library our EOL policy is a great benefit so us as > > it dramatically lowers our maint burden. This makes it worth the cost > > for people who might wish to deploy libvirt on older systems. > > > > The language bindings do not have a high maint cost from supporting > > old versions, so it doesn't justify creating pain for application > > developers by dropping support so aggressively as for main libvirt. > > > > A time based scheme for dropping old versions in language bindings > > is very easy to describe to people & apply ourselves, more so than > > our main policy which needs us to research versions across distros > > every time we change something. > > It seems to me that people who want to run the latest version of > whatever application will also use a non-obsolete operating system, > and conversely people stuck with an old OS will rather also stick to > the vendor-provided (and -supported) versions of the various > components rather than installing newer ones from source. > > It's basically the same argument we used to justify libvirt dropping > support for old operating systems and old QEMU versions, and I think > it still applies when you take it one layer up the stack. It is the difference between the OS infrastructure layer and the application layer. Essentially what I'm saying is that libvirt is part of the OS infrastructure, and the libvirt language bindings are part of the application infrastructure. It is valid to deploy on an old OS with vendor supplied libvirt, while still using brand new libvirt python/Go bundled with the application, not using the OS vendor provided version. The latter is in fact the recommended approach for application developers in RHEL these days. We ship libvirt-python in RHEL-8 built against the system python for use by virt tools we ship like virt-install, virt-manager. From a support POV 3rd party application developers are not supposed to use system python, instead they must pick a python module stream. If they're lucky their python module is the same version as system python and they can use the system libvirt-python, but in general they are expected to ship libvirt-python themselves as part of their application install. > If anything, the higher you go up the stack and the more developers > are okay with having tighter coupling between their application and > libvirt/QEMU versions, so I'd say it actually applies even more to > them. I don't believe you can make such a blanket assertion about tight coupling. I've seen both from apps developing against a very specific min libvirt version only, vs apps developing against a range of libvirt versions. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
