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