[Xcb] [ANNOUNCE] xcb-util 0.3.9

[Jeremy C. Reed]

On Mon, 4 Jun 2012, Jeremy Huddleston wrote:

> On Jun 4, 2012, at 1:34 PM, Julien Cristau <jcristau at debian.org> wrote:
> 
> > On Sat, Jun  2, 2012 at 16:41:02 -0700, Jeremy Huddleston wrote:
> > 
> >> Why did "Do not rely anymore on gperf and m4 following removal of deprecated atoms." do this:
> >> 
> >> -libxcb_util_la_LDFLAGS = -version-info 0:0:0 -no-undefined
> >> +libxcb_util_la_LDFLAGS = -version-info 1:0:0 -no-undefined
> >> 
> >> I don't see this change requiring a major version bump which should
> >> only be done for binary compatibility changes.  Yes, you removed the
> >> xcb_atom_get_predefined and xcb_atom_get_name_predefined functions,
> >> but not in a binary incompatible way, so you should not have bumped
> >> the major version which requires relinking every library and
> >> application that links against the library.
> >> 
> > How are the xcb_atom_get_predefined/xcb_atom_get_name_predefined
> > removals not binary incompatible??
> 
> Nothing else changed, just the removal of the symbols.  All other 
> functions did not change their signatures.
> 
> 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.

>From a libtool point-of-view, -version-info change looks correct for 
interface removal: "current" is incremented and revision and age are set 
to 0.