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 > changed. > > 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 etc). 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). -- Sébastien _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list