[libvirt] Limiting old version back compat for language bindings ?

[Daniel P. Berrangé]

In at least the Python and Go bindings for libvirt we use conditional
compilation to allow the bindings to be build against old versions of
libvirt.

For Python this goes back to 0.9.11, from Apr 2012

For Go this goes back to 1.2.0, from Dec 2013

I'm wondering whether it would be worthwhile to define some rule to set
a historical maximum, beyond which we will drop conditional compilation,
or whether we're ok letting it grow without bound.

The conditional compilation of code has some maint cost, but the cost
is not huge, so I don't think this is something we need to be too
aggressive on.

At the same time I'm sceptical anyone is using latest Python bindings
with libvirt 0.9.11, or latest Go bindings with libvirt 1.2.0


The challenge with language bindings is that users will often not use
the language binding provided by the host OS vendor, instead preferring
to download & build themselves.

IOW, the host OS can have libvirt 3.0.0, but the app will be blindly
pulling latest python binding (4.8.0) from PyPI and expect it to work.

Of course if they're on an old distro, they could just pull an older
version of the binding. Having to write code to download different
version of the binding code on each OS is costly though, and indeed
not even supported by common build tools.

eg in python requirements.txt you can allow it to pick the latest
version, or you can set an explicit version. The problem comes if
you want to build on an OS with version 3.0.0, but also want to be
able to use APIs from 4.0.0 if its available. AFAIK, you can't
express this with distutils/setuptools.

The same issue arises with the way you express deps in Go modules.
You can ask for a specific version, but can't say to use a
different version on certain OS.

The key question is thus how far back applications should reasonably
expect us to support language bindings. LTS distros live for quite
a long time & its not unreasonable for apps to target them.

In RHEL we've tended to rebase libvirt frequently while that RHEL
version was the latest. That means we have

  RHEL-6  - 0.10.2
  RHEL-7  - 4.5.0
  RHEL-8  - 4.5.0

Considering Ubuntu LTS which doesn't rebase we have

 Trusty 14.04 - 1.2.2
 Xenial 16.04 - 1.3.1
 Bionic 18.04 - 4.0.0

Given this is only low/moderate maint cost, I'm tempted to be quite
generous to applications and say that in January each year, we purge
support for versions older than 5 years. 

This would imply...

 - Jan 2020 - purge older than 1.2.12 (Jan 2015)   (Drops Trusty)
 - Jan 2021 - purge older than 1.3.1  (Jan 2016)
 - Jan 2022 - purge older than 3.0.0  (Jan 2017)   (Drops Xenial)
 - Jan 2023 - purge older than 4.0.0  (Jan 2018)
 - Jan 2024 - purge older than 5.0.0  (Jan 2019)   (drops RHEL-7, Bionic)
 - Jan 2025 - purge older than 6.0.0  (Jan 2020)

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