Re: [Libusb-devel] libusb API changes

[Orin E. <ori...@gm...>]

On Wed, Jul 13, 2011 at 9:30 AM, Pete Batard <pe...@ak...> wrote:

> On 2011.07.13 14:43, Vitali Lovich wrote:
> > Basically libusb will have lost source & binary compatibility
>
> How would that affect you exactly? Can you clarify the worst case
> scenario for doing it outside of a dot release for your application?
>
> I'm not saying that we should perform API changes in 1.0.9 or 1.0.10
> (and I'm not speaking as someone who has much weight with regards to
> future libusb API changes anyway), but given the hellishly *slow* rate
> of release of libusb, I kind of fail to see how modifying the next
> version of your app after a libusb API change, to use the new API calls,
> while telling your users to only use libusb version x.y.z or later, with
> y and z not necessarily being zero, is going to be that much of a
> problem. It's not like there will be much confusion about which libusb
> version to use and the extra work incurred on you by this change also
> seems quite limited. Also, even if you invite your end users to only use
> 1.0, you can be certain that there will be some who want to use 1.1 or
> 2.0 regardless, so you will have to provide an updated version of your
> app eventually anyway. Or do you expect your app to use a libusb shared
> library and have to compete with another app that would require the old
> calls, and would be unlikely to be updated to use the new calls as yours
> would be?
>


Don't forget the licensing of libusb which requires that users be able to
upgrade their version of libusb.  For closed-source users, this is usually
accomplished by shipping a DLL or equivalent and instructions to upgrade.
It's what I did for the Mac.  We still ship 1.0.6 as we don't have the QA
resources to test a later version.  Note that it's not a matter with
competing with an other application that's using a shared library; we
install our own copy in a private location.  It's a matter of allowing the
user to upgrade to a later version that is also installed in our private
location.

I'd expect any 1.x.y to work and be backwards (binary API) compatible.  If
an API was ifdef'd out of a 1.x.y release, then I'd have to make my own
1.x.y release and put it back in.  You'd have a fork, although with somewhat
limited distribution.  I'm not saying we'd officially support 1.x.y, only
that we'd make it possible for the user to upgrade.

This is the kind of thing that gives Windows developers at Microsoft
nightmares.  They simply aren't allowed to break existing applications that
are using the APIs correctly (and no doubt many that are using the APIs
incorrectly).  I believe that libusb should have the same mentality - binary
compatibility with existing applications that expect the version to be >=
1.a.b and < 2.0.0 for all 1.x.y where x.y >= a.b .

Orin.