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

[Sébastien Wilmet <swilmet gnome org>]

On Thu, Dec 14, 2017 at 08:34:51PM +0000, Emmanuele Bassi wrote:
> On 14 December 2017 at 18:42, Sébastien Wilmet <swilmet gnome org> wrote:
> > A recent example:
> > https://git.gnome.org/browse/gtk+/commit/?id=2d5c82b4ecbe6ff534a1b9476080e409742daa39
> > "gtk: Remove GtkClipboard"
> >
> > The clipboard is now implemented in GDK. GtkClipboard is not deprecated
> > in GTK+ 3.22, and the new API is not available in GDK 3.22.
>
> The new API just landed; and, yes: it's hard to deprecate the API in
> this case, given that the new API has been moved down one level in the
> hierarchy.

GDK, GSK and GTK are now part of the same *.so library. If GtkClipboard
still worked fine just before the commit that removed it, it would have
been possible to first deprecate GtkClipboard and then removing it in
3.9x+2 (see my comment below).

Of course if GtkClipboard didn't work anymore, then it needed to be
removed. Or maybe it was possible to port GtkClipboard to the new GDK
API, but this would have been more work for the GTK developers. It all
depends if you want to provide a smooth experience to port apps.

> Doing this work in 5 years, for GTK+ 5.0,
> would not have been any easier for anybody.

I don't understand why you say that. Each semi-stable 3.9x version can
be seen as a new major version, since it's possible to break the API. So
an API can be marked as deprecated in 3.92 and then removed in 3.94.
Instead of doing a direct API break. This would make it easier to port
applications.

--
Sébastien