[Xcb] [ANNOUNCE] xcb-util 0.3.9

[Josh Triplett]

On Mon, Jun 04, 2012 at 02:52:51PM -0700, Jeremy Huddleston wrote:
> On Jun 4, 2012, at 2:19 PM, Adam Jackson <ajax at redhat.com> wrote:
> > On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
> >> On Jun 4, 2012, at 1:34 PM, Julien Cristau <jcristau at debian.org> wrote:
> >> Think about this from the libc perspective.  libc *may have* strlcat
> >> or not, but they're named the same because all functions in libc have
> >> consistent signatures.
> > 
> > A libc that had strlcat once, and then removed it, would no longer have
> > the same ABI.  An application that had successfully linked against the
> > old libc's strlcat would reasonably expect it to be present at runtime
> > too.
> 
> That argument breaks down when you reverse it.  The "rules" state that the SONAME should not change when adding APIs.  If all you're basing this on is SONAME, then there is absolutely no difference between the adding and removing case.  If I link against a "newer" libc which has strlcat, then by your argument, I'd expect strlcat to be present on any libc matching that SONAME.  When I run my application with the older libc without strlcat, it will fail to find it.

That represents the difference between major and minor version changes.
When you add a new function (or otherwise extend the ABI, such as by
adding new flags to a flags parameter), you increase the minor version,
so that applications built against the new library won't run with the
old one, but applications built against the old one (and thus not
expecting the new function) will still work with the new library.
However, when you *remove* a function, applications built against the
old library will not work with the new one, so you have to bump the
major version.

> SONAME is not the solution to this problem.  The best practice is to properly annotate "new" functions (so they are weak linked) and not remove public API until it is really warranted.
> 
> If you're removing a fringe API that is only used internally, then I'd argue against SONAME change.

Only if you know for sure that it won't break any real applications; in
other words, does this represent de-facto public API, or not?

- Josh Triplett