Re: First deprecate APIs and then remove them in the next major version

[Christian Schoenebeck <schoenebeck linuxsampler org>]

On Samstag, 16. Dezember 2017 12:05:03 CET Sébastien Wilmet wrote:
> On Fri, Dec 15, 2017 at 11:10:46AM -0500, Matthias Clasen wrote:
> > I know this may sound harsh, but: If you want things to work differently,
> > send patches.

In theory. In practice you send patches and then you get a response like "hmm, 
not sure about that, I would like to have it differently", and that without an 
actual suggestion how to do that "differently".

Like you said, if you want things differently, send your patches. But then as 
a patch sender you have the same expectation: you don't like the patch, make a 
better suggestion! You don't have a better suggestion or at least an adequate 
feedback? Ok, then apply the patch and simply add FIXME comment(s) at your own 
discretion and maybe one day somebody replaces it with a better solution.

Just one example, gtk3 (yes 3, not even 4) is currently completely unusable on 
Mac, so I sent a patch to fix this:

        https://bugzilla.gnome.org/show_bug.cgi?id=791174

I know my patch is suboptimal, but to make this clear: it does not address a 
minor bug, this bug is a real show stopper on Mac, and this change is purely 
gtk internal. Of course it is not a clean solution, but there is no reason to 
simply apply this patch (at a bare minimum at least to the gtk3/stable branch) 
with a FIXME comment for now so that people on Mac can finally start using gtk3 
at all.

> > Maintaining compatibility layers costs and constantly gets in the way of
> > large-scale
> > refactorings like the ones that are happening in gtk 3.9x now.
> >
> > Note that we haven't really asked application developers to port to the
> > current 3.9x releases
> > yet, because they are still in flux.
>
> About the cost of compatibility layers, it reminds me an economics
> principle with game theory and cooperation, for example with the
> prisoner's dilemma:
> https://en.wikipedia.org/wiki/Prisoner%27s_dilemma#Strategy_for_the_prisoner
> 's_dilemma
>
> With cooperation and compatibility layers in GTK, GTK would move forward
> less quickly, but it would maybe yield a better outcome globally when
> taking into account higher-level libraries and applications.

This is always the common argument "retaining old APIs means more work". But 
if you look at what APIs had been removed in gtk (and glib and co) in the 
past, most of them could have been preserved with no or little effort on 
library level.

I mean to me it looks like nobody even considered in the past to keep old APIs 
at all. Currently it is just a common rule "ok, we are now on the next major 
version branch, we are now safe to do whatever we want to do, so let's start 
removing everything we don't like anymore".

Addressing major library changes on application level often means *much* more 
effort, because as application you don't necessarily have access to library 
internal things nor can you make certain presumptions. Plus not only one gtk 
app project has to do that gtk version compatibility work, all gtk app 
projects need to do them.  If you calculate how many man hours are wasted on 
all these applications, just for retaining compatiblity with the latest major 
gtk version, then you probably might see that the trash can decisions are 
currently made far too easily on library level.

CU
Christian