- Date: Sun, 14 Aug 2016 15:56:23 +0200
- From: Sébastien Wilmet <swilmet@xxxxxxxxx>
- Subject: Re: Gtk+4.0
On Sun, Aug 14, 2016 at 09:03:23AM -0400, Morten Welinder wrote:
> > When GTK+ breaks the API, it doesn't mean that a higher-level library
> > needs to break API too.
> That depends.
> You are right that a lot of API changes can be hidden.
> But if the higher-level library has an API that includes a type
> which is being removed, then the API will have to be
> And if your library depends on a feature that is being removed
> then your library probably cannot be saved with an API break.
Higher-level libraries can do their best to keep backward compatibility,
but when it is not possible, the higher-level library will also need to
bump the SONAME (without full parallel-installability for the headers
As long as the higher-level libraries communicate this clearly to their
users, I don't see it as a problem.
Of course a higher-level library developer can decide *not* to follow
GTK+ unstable, which forces some applications to also stay at GTK+
stable. Which can be a problem (the same problem with Python libraries
that are not yet ported to Python 3, so some programs are stuck at
gtk-devel-list mailing list