Re: First deprecate APIs and then remove them in the next major version
- Date: Sat, 16 Dec 2017 15:12:06 +0100
- From: Christian Schoenebeck <schoenebeck@xxxxxxxxxxxxxxxx>
- Subject: Re: First deprecate APIs and then remove them in the next major version
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:
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
> > 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:
> 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
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.
gtk-devel-list mailing list