Hi, On Mon, Apr 23, 2012 at 11:12:22AM +0100, Pete Batard wrote: > We *will* deviate in an incompatible fashion sooner rather than later. > To me, trying to delay this inevitability doesn't seem very productive. ... > On 2012.04.23 08:40, Hans de Goede wrote: > > IMHO in this case maintaining ABI compatibility trumps your concerns > > about these strings.
First of all, a BIG Thank You for taking action to improve the libusb situation. However, I have a feeling that your strategy to replace libusb is not completely thought out yet. ;-/ - as Pete noticed, libusb and libusbx will diverge, so there is no point trying to maintain ABI compatibility - if you think Peter will stop working on libusb and/or take another two years for the next release, I'm afraid it looks like he is determined to prove you wrong - sooner or later applications will depend on incompatible features of libusb or libusbx, thus there is a requirement to be able to have both libusb *and* libusbx packages in distributions Probably we'd all be much better off if you forget about libusb completely and just do your own thing. After all, "libusb is dead" is what you said so you should treat it as such. Stop caring what Peter does with it. Application developers will use libusbx if it delivers what libusb fails to provide. I'm convinced you need to give libusbx it's own soname, library and include file name and allow application developers to make a deliberate choice. Johannes ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
