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

[Christian Schoenebeck <schoenebeck linuxsampler org>]

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 to 
stick with gtk version x, like some projects already did for such reasons as 
mentioned by Sébastien.

> 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 the 
API and in which way exactly. I am fine with that. Another thing is to decide 
on behalf of *all* application developers "you should no longer use such kind 
of features in your app - so we removed them". The latter is something which 
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ébastien 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