Re: [Xcb] [ANNOUNCE] xcb-util 0.3.9

[Jeremy Huddleston <jeremyhu@xxxxxxxxxxxxxxx>]

On Jun 3, 2012, at 18:54, Arnaud Fontaine <arnau@xxxxxxxxxx> wrote:

> Hello,
> 
> Jeremy Huddleston <jeremyhu@xxxxxxxxxxxxxxx> writes:
> 
>> 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.
> 
> I don't  really understand why it  does not require a  bump of "current"
> number.

glibtool supports two modes of versioning:

version-info is current/revision/age based

version-number is major/minor/tiny based

The former confuses the heck out of me, and I always need to lookup documentation for it.  I suggest you might want to switch to version-number.

> Could you please elaborate?
> I followed that documentation[0] and
> as I thought that some other  libraries or program could have used these
> functions, I bumped "current" version.  It made sense at that time but I
> may be wrong though...
> 
>> How do you want to fix this?  Is  this a flag day, and it won't happen
>> again, or do you want to do  a quick turn-around release of 0.3.10 and
>> recommend that nobody ship 0.3.9?
> 
> If I would have to revert this change, I would prefer the first option.
> 
> Cheers,
> -- 
> Arnaud Fontaine
> 
_______________________________________________
xorg@xxxxxxxxxxx: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: list-xorg@xxxxxxxxxxx