[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: First deprecate APIs and then remove them in the next major version
From:       Christian Schoenebeck <schoenebeck () linuxsampler ! org>
Date:       2017-12-13 18:37:24
Message-ID: 137564078.aFJ5R97Ofs () silver
[Download RAW message or body]

On Mittwoch, 13. Dezember 2017 16:55:41 CET Emmanuele Bassi wrote:
>  - GTK supports parallel installation of different major API versions
>  - symbols, types, properties, and signals deprecated in a major API
> version continue to exist forever (and possibly work as well)
>  - new major versions remove the deprecated API from the previous
> major API version
>  - application developers port their projects between major versions
> at their own leisure
> =

> The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22
> beforehand.

I think most people on this list know these things already. ;-)

> We are not talking about remove API inside the same major version.
> =

> Porting applications between major versions is its own effort, just
> like porting an application from Windows Vista to Windows 10, or from
> macOS 10.6 to 10.12.

Well, but you also know that their APIs are much more long-term stable than =

gtk, to a large percentage even ABI stable.

From my personal experience at least, maintaining an application on top of =

gtk(mm) means more effort than mainining an application on top of any other =

major application level framework. Unless you decide for your application t=
o =

stick with gtk version x, like some projects already did for such reasons a=
s =

mentioned by S=E9bastien.

> Not every new feature or replacement will be 1:1 with deprecated API.
> We did not deprecate something because we were tired of how it's
> named: we deprecated it because some things should not be done any

Mja, it is one thing to decide which internal things should be exposed to t=
he =

API and in which way exactly. I am fine with that. Another thing is to deci=
de =

on behalf of *all* application developers "you should no longer use such ki=
nd =

of features in your app - so we removed them". The latter is something whic=
h =

should clearly be avoided in a framework as much as possible.

I'm logging out from this topic now, but I definitely agree with S=E9bastie=
n and =

I also share the opinon that many gtk decisions gave me the impression that =

they were not made from an application developer perspective.

CU
Christian
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]