On Sun, Mar 09, 2008 at 12:52:57PM +0800, Deng Xiyue <[EMAIL PROTECTED]> was heard to say: > Daniel Burrows <[EMAIL PROTECTED]> writes: > > If you want to help out, please do so. The main problem is that I > > haven't had time to analyze the new release and see what's in it: is it > > a release for new features, for bugfixes, for internal redesign; is it > > source-compatible so that it can replace 2.0, or do I need to create a > > new series of packages; if it's source-compatible, does it need a soname > > bump; etc.
I've taken a look at it now. As far as I can tell, basically this is just a source-incompatible change that introduces new typedefs that will be used by fairly few programs (mostly those that iterate over signal binding lists) and drops some old names for things. Why is it so urgent to upload this new version? Is software using these new features already? I don't see anything else of note in the NEWS file or in the changelog. > The ChangeLog contains various changes happened after 2.0.17, which > are mainly removal of deprecated compatibility api, many new > interfaces are added, and several bug fixes. But it seems no ABI > changes happened, so it should be source compatible (any breakage > other than deprecated api should be bugs) and there is no shared > library soversion bump (as it is still unversioned). I suggest an > upload to experimental ASAP to help testing. If you permit, I'll try > to do the work and let you review. It is not source-compatible. In particular, sigc::slot, a type that gets used all over if you ever want to store a callback for future use, is no longer pulled in from slot.h; you need to #include <functors/slot.h> instead. I haven't yet investigated whether this is the only problem, but I doubt aptitude is the only program that runs into this. I'll upload packages to experimental, but I don't think that charging ahead with this is a good idea right now. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
