But what does that mean?
To me it means that updating API/ABI stable libraries should not
break existing applications. This should not keep one from fixing
bugs — if you depend on those you get what you deserve — but
existing, well-defined, well-documented interfaces ought to continue working as previous.
The recent updating-glib-breaks-pango issue could, with a little good will, be considered a case of a
bug in old pango that now have triggered.
But what about the new updating-gtk+-breaks-stuff issue? Evidently soneone though it would be nice to change the basic ways reference counts are handled for GTK+ objects. That causes leaks, and leaks for widgets can mean they stay visible when they should not have been, i.e., applications are now broken. This is not right!
There is some talk about fixing the GTK_OBJECT_SET_FLAGS macro (and presumably the GTK_OBJECT_FLOATING macro) to plaster over the issue and regain some amount of API compatibility. The ABIs would remain incompatible,
so someone updating their libraries would still see their
applications break and come to me.
What can I as an application programmer do about this?
- Demand that the GTK+ changes be rolled back. That would be the right
thing to do and is a very reasonable demand. They could go back in for GTK+ 3.
- Throw in some “incompatible with GTK+ 2.9 and later” dependency
and get it deployed. Awful, right? Deployment is a multi-year
- Rush in some devious works-both-places code and get that
deployed. Marginally less awful, but still suffers from the deployment delay.
Incidentally, it is not at all clear what tangible benefit there
is to the changed reference count scheme. I am all ears.