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