ABI report for Vermillion Devel 63

[Brian Cameron]

Alo:

When we run the ABI reports, we run them against all the libraries in
the GNOME Platform.  Our "Committed" library interfaces are a subset
of these (plus we check D-Bus since we have a contract with the HAL
team to keep these interfaces stable).  Strictly speaking, we only
really need to ensure interface stability in Committed libraries and
library interfaces for which we have a contract with another Sun
project.

The main reason we check all Platform libraries is as a service to
the GNOME community.  If ABI breaks in these interfaces, this could be
caused by a breakage in their ABI rules.  Therefore, normally we should
not see functions removed in any of these libraries.  If we do, and if
the interfaces are provided by the GNOME community, then we would
obviously want to let them know about the potential breakage.  Some
Solaris users may be depending on GNOME ABI promises, so it is good for
us to keep an eye on this to avoid undue stress for such Solaris users
(even though we aren't stricly "Committed" to do so).  Fortunately the
GNOME community does a pretty good job here, and since we started doing
ABI checking, we haven't seen any real issues in this area.

Note that sometimes we do see functions removed.  This is not a problem
if the functions are not exposed in header files.  We have done some
work with the GNOME community to better hide private/hidden functions,
but this is an area where more energy could be focused.

Obviously, in a case like this where we add special functions to a
Platform library via a patch or whatnot, then this is a special case and
not covered by the GNOME ABI rules.

>   What I can do for sure is to re-implement the methods I removed. I
>   suppose that would be a little help even if they are deprecated.
> 
>   About the ABI stability issue, I don't remember who I talked with,
>   but my understanding was that as long as it was the gnome-vfs lib it
>   wasn't a big deal.  At the end of the day, the ABI is not guaranteed
>   to be stable.

While this is not a "bad" ABI breakage, it could potentially cause
confusion among Solaris users.  Since gnome-vfs is a part of the GNOME
Platform, end-users could easily think that any interfaces exposed in
these libraries are okay for them to use - especially if they are
exposed in the header files and/or mentioned in the generated gtk-docs.

Therefore, we should try to avoid adding such functions unless there is
a strong case.  We also should avoid putting them in the header files
(if possible), and probably should avoid mentioning them in the gtk-docs
unless we are willing to also honor the GNOME community ABI rules.

If new interfaces are needed, can we work with the gnome-vfs community
to get these interfaces added upstream?  If, on  Solaris, we need
special functionality in gnome-vfs, would it be possible to add a plugin
interface upstream so we can add such new functions in a generic,
plugin-able fashion?

This would be better, obviously, then just adding new interfaces to
a library that has an ABI promise from the GNOME community.  We should
try to honor the same ABI promises for GNOME Platform libraries
whenever possible.

I hope this clarifies the issues here, and why we check ABI for
libraries even though they aren't strictly Committed.

Brian