[libvirt] [RFC 0/7] Warn at runtime when deprecated features are used

[Daniel P. Berrangé]

On Thu, Oct 04, 2018 at 04:08:31PM +0200, Andrea Bolognani wrote:
> On Thu, 2018-10-04 at 14:02 +0100, Daniel P. Berrangé wrote:
> > On Thu, Oct 04, 2018 at 01:38:33PM +0200, Andrea Bolognani wrote:
> > > GTK+ does it, Qt does it; and I'm willing to bet there are more
> > > applications linking against either of them than there are linking
> > > against libvirt.
> > 
> > I don't think that's a positive example. As a developer who has
> > used GTK for multiple apps, I *hate* their frequent API deprecations
> > during minor updates. It is a constant battle to keep app code
> > compiling cleanly even within a single releae, no to mention the
> > even greater pain of trying to do GTK2 and GTK3 in parallel.
> > 
> > Sure, this deprecation and deletion of code benefits the GTK
> > maintainers, but the cost of creating ongoing pain for every
> > single application developer. That's not a net win IMHO as the
> > set of app developers is much larger.
> 
> I think keeping up with changes in libraries you consume is simply
> due diligence for developers, and while of course that takes up
> some of your time and is for the most part hardly a glamorous job,
> it also ensures your application is in tip-top shape at any given
> time and is taking advantage of all possible improvements in the
> underlying tech by periodically reconsidering parts of its design,
> which will ultimately result in a better experience for users.

Changing existing code to use new APIs doesn't imply the app
is in tip-top shape. On the contrary, I can arguably make it
more likely to break in subtle ways by changing something which
is long tested in the field for something new & relatively
untested.

> And libvirt developers themselves not having to tiptoe around what
> is in some cases quite literally a decade worth of backwards
> compatibility hacks would allow them to focus on features and bug
> fixes that actually impact users in a positive way, all the while
> keeping the size of the library from growing out of control, with
> all the resource usage and attack suface consideration that entails.

Maintaining API compatibility is not really the main contributor
to resource usage or attack surface. That is a large architectural
issue, such as the monolithic libvirtd and usage memory unsafe
language for impl. Deprecating & removing features or changing
defaults will have negligible impact.

> > As a counter point, Microsoft Windows never breaks its APIs and
> > that has many orders of magnitude more app developers than GTK/Qt
> 
> How many of the bugs and crashes experienced daily by Windows users
> could be avoided if applications were forced to adopt newer, safer
> APIs over time instead of being allowed to lazily stick to whatever
> was available at the time Windows 95 was the new hotness?

The idea that you can force people to adapt is flawed. Some devs
may adapt. Others simply won't so an app that otherwise worked
fine will now be needlessly broken. Others will simply bundle
the older version of your API in their code getting stuck on
old outdated insecure versions.

> Your guess is as good as mine, but I'm pretty sure the answer is
> not "zero".

Adapting to new APIs will itself introduce new bugs. Libvirt has felt
this when we've had to adapt to APIs changing in things we use too.

> > The fact that libvirt never breaks API is one of our greatest
> > selling points.
> 
> I don't have hard data on this, but I suspect the success of
> libvirt is driven more by the great features it offers than its
> promise to preserve API/ABI compatibility forever; even more so
> considering that the majority of Open Source projects don't offer
> anything close to the latter, and yet somehow manage to thrive.

GTK's API breakage means that we still have applications in Fedora
that are stuck on GTK1, despite fact that GTK3 is current and GTK4
is coming soon. The world of hurt caused by Python's gratuituous
incompatbilities between py2 and py3 is going to continue to harm
the python community for years to come.

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