Hi Jim, On Monday, 18. June 2012 20:32:52 Jim Paris wrote: > What APIs were broken between libftdi-0.x and libftdi-1.x? Can they > be fixed? Even if not, we should strive to maintain compatibility in > the future so we don't just run into this problem again. For example, > adding a version or size field to struct ftdi_context would let us > determine in the library which API the binary was compiled against. > For functions with a changed implementation, the old implementation > should be maintained as-is or with a compatibility shim, and the new > implemtation should be given a new name.
Thanks for your feedback. There are multiple things that will break backward compatibility in the binary data structures: - We expose variables. So far nobody had time to provide set/get functions. I also don't want to delay a libftdi 1.0 release because of this. It's already painful that two library versions are actively used. - We expose the raw libusb device. This structure will certainly change when upgrading from libusb 0.x to libusb 1.x :) - (Experimental) async API is totally different > Ulrich Drepper's Good Practices in library design, implementation, and > maintenance: http://www.akkadia.org/drepper/goodpractice.pdf > Ulrich Drepper's How to write shared libraries: > http://www.akkadia.org/drepper/dsohowto.pdf > Mike Hearn's Writing shared libraries: > http://plan99.net/~mike/writing-shared-libraries.html > > With the right design and care on the library end, the API can be made > stable enough that a user application can simply include the system's > single /usr/include/ftdi.h and be confident that the code will still > continue to compile and run correctly even if a new version of libftdi > is installed. Thanks for sharing the links, quite a good read. Might be an option for the future, if anybody provides patches for this :) Thomas -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
