On Jun 3, 2012, at 18:54, Arnaud Fontaine <ar...@debian.org> wrote:
> Hello, > > Jeremy Huddleston <jerem...@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" > 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@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
