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
Python 2).


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