[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 16:34:44
Message-ID: 1792077.R9QcqS5bG6 () silver
[Download RAW message or body]

On Mittwoch, 13. Dezember 2017 12:33:34 CET Emmanuele Bassi wrote:
> On 13 December 2017 at 12:05, S=E9bastien Wilmet <swilmet@gnome.org> wrot=
e:
> > 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, Q=
t, =

etc. are actually all handling it as expected by application developers; th=
at =

is they usually deprecate old APIs and retain them for many years before th=
ey =

eventually (if at all) remove them one day. It is rare that they remove API=
s =

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, ev=
en =

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 =

released.

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]