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

[Matthias Clasen <matthias clasen gmail com>]

On Sat, Dec 16, 2017 at 9:12 AM, Christian Schoenebeck <schoenebeck linuxsampler org> wrote:

>
> 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".

Maybe give a concrete example of an api that we could have 'preserved with no effort"

and yet removed out of folly ? I would be interested.

 

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.

To me this reads like a misunderstanding.

Moving an application from GTK3 to GTK4 means porting work. But you do it only once,

and you don't retain GTK3 compatibility. At least, that is not what the GTK+ team

recommends you should do.

If you want to stick with GTK3, you are more than welcome to do so for years to come.