xcb-util 0.3.9 is now available. git tag 0.3.9 Changelog ========Arnaud Fontaine (4): Remove xcb_bitops.h. Do not rely anymore on gperf and m4 following removal of deprecated atoms. Add autogen.sh to EXTRA_DIST. Release 0.3.9 Download =======http://xcb.freedesktop.org/dist/xcb-util-0.3.9.tar.bz2 md5: 01dcc7a16d5020530552712710646ea2 sha1: 02060d8e2e70838fc41cd3a27c7f2909090d8c20 sha256: c611259c0ab20fd76f79f48f4684843c18ea9c967eba78a45e8b3636315c18c4 http://xcb.freedesktop.org/dist/xcb-util-0.3.9.tar.gz md5: ca04b25d913239a3ef94b688f7ac38cd sha1: a2ad356922927d2a7f24ef4d8ea1b00b92f78a21 sha256: c3f9e8921998d92b3709baeb6c0b78179d0d8b6f592efdb11120584c5dfedc7e -- Arnaud Fontaine -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.x.org/archives/xorg-announce/attachments/20120531/0c7b4854/attachment.pgp>
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 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? --Jeremy On May 30, 2012, at 20:57, Arnaud Fontaine <arnau at debian.org> wrote:> xcb-util 0.3.9 is now available. > > git tag 0.3.9 > > Changelog > ========> Arnaud Fontaine (4): > Remove xcb_bitops.h. > Do not rely anymore on gperf and m4 following removal of deprecated atoms. > Add autogen.sh to EXTRA_DIST. > Release 0.3.9 > > Download > =======> http://xcb.freedesktop.org/dist/xcb-util-0.3.9.tar.bz2 > md5: 01dcc7a16d5020530552712710646ea2 > sha1: 02060d8e2e70838fc41cd3a27c7f2909090d8c20 > sha256: c611259c0ab20fd76f79f48f4684843c18ea9c967eba78a45e8b3636315c18c4 > > http://xcb.freedesktop.org/dist/xcb-util-0.3.9.tar.gz > md5: ca04b25d913239a3ef94b688f7ac38cd > sha1: a2ad356922927d2a7f24ef4d8ea1b00b92f78a21 > sha256: c3f9e8921998d92b3709baeb6c0b78179d0d8b6f592efdb11120584c5dfedc7e > > -- > Arnaud Fontaine > _______________________________________________ > Xcb mailing list > Xcb at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xcb
On Jun 3, 2012, at 18:54, Arnaud Fontaine <arnau at debian.org> wrote:> Hello, > > 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" > 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 >