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

Reply via email to