Re: First deprecate APIs and then remove them in the next major version
- Date: Wed, 13 Dec 2017 17:34:44 +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 12:33:34 CET Emmanuele Bassi wrote:
> On 13 December 2017 at 12:05, Sébastien Wilmet <swilmet@xxxxxxxxx> wrote:
> > Ideally, a new major version of a library should only remove deprecated
> > APIs.
> The short answer is: that's not how library development works, unless
> you have a small enough library whose API is inconsequential, or it's
> used only by a handful of projects. GTK is neither.
The most popular application level frameworks i.e. from Apple, Microsoft, Qt,
etc. are actually all handling it as expected by application developers; that
is they usually deprecate old APIs and retain them for many years before they
eventually (if at all) remove them one day. It is rare that they remove APIs
without deprecating them first, and in such rare cases there are "usually"
profound reasons like security aspects (or -cough- "product policies").
> If we just removed deprecated API without adding any new feature,
> there would be no incentive whatsoever to port applications to a new
> major version, which will result in an untested API that we cannot
> change until the next major release cycle.
Personally I feel with him, although I can live with APIs being removed, even
without a deprecation phase. A much bigger problem that I see is when
replacement APIs are introduced which are missing features from their
predecessors. That happened with at least every major release of Gtk, and I
see this to happen with Gtk 4 again. I hope some of my patches will be
accepted to fix a couple of those issues before Gtk 4 will be officially
gtk-devel-list mailing list