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

On 14 December 2017 at 18:42, Sébastien Wilmet <swilmet gnome org> wrote:
On Wed, Dec 13, 2017 at 04:55:41PM +0000, Emmanuele Bassi wrote:
The API that gets removed in GTK+ 3.9x is deprecated in GTK+ 3.22 beforehand.

No, that's not true.

A recent example:
"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

This is also why we could not do this during the 3.x API cycle,
without incurring into a lot of regressions or potential breakage.

I think Benjamin has done a great work with the new implementation. Just
a little problem: it's what I call a "direct API break", applications or
higher-level libraries will need to be ported from GTK+ 3.92 to 3.94
with a big API delta, so it will result in one huge commit/branch
untestable until all the code is ported [1].

That's what we said would happen during the 9x development cycle: no
API stability between 9x and 9x+2. We were very much upfront about the
API stability.

It's of course much worse
if porting directly from 3.22 to 4.0.

And we understand that. Doing this work in 5 years, for GTK+ 5.0,
would not have been any easier for anybody.

[1] What I would recommend is to copy custom widgets/containers (if they
are self-contained) out-of-tree, and port them individually, with a
small GUI test program for each, so that they can be tested outside the
whole application.

That would not help at all for the GtkClipboard case, and that would
not help with the new rendering API.

I'm sorry about the pain in porting, but this is what 2.5 years of
development are for.


[@] ebassi []

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]