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

[Daniel P. Berrangé]

On Mon, Oct 07, 2019 at 01:58:10PM +0200, Andrea Bolognani wrote:
> On Mon, 2019-10-07 at 12:13 +0100, Daniel P. Berrangé wrote:
> > 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)
> 
> 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.

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