[Xcb] [ANNOUNCE] xcb-util 0.3.9
jeremyhu at freedesktop.org
Sun Jun 3 23:38:52 PDT 2012
On Jun 3, 2012, at 18:54, Arnaud Fontaine <arnau at debian.org> wrote:
> Jeremy Huddleston <jeremyhu at freedesktop.org> 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"
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 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.
> Arnaud Fontaine
More information about the xorg-announce