This was ignored because libtool versioning doesn't work that great for a cross
platform library that can produce a Windows DLL (especially if compiled from
MSVC where none of what is declared in `configure.ac` applies).
The preferred way of checking for incompatibilities is to use
[`LIBUSBX_API_VERSION`](http://libusbx.sourceforge.net/api-1.0/group__misc.html#gaa83ecded256e0767220bcc21cc92365d)
in your application code.
As you will see with the [hotplug
calls](http://libusbx.sourceforge.net/api-1.0/group__hotplug.html#ga4868157346bbf2c70b6af0cb0a6c0094),
we do try to document the minimal `LIBUSBX_API` version to use for new API
calls.
Granted, this is not as convenient as letting libtool do it, but unless you
know of a good way to handle a cross-platform API versioning, that doesn't
leave Windows out, I'm not sure we want to multiply the versioning numbers we
need to alter, as I'm pretty sure we're going to forget to keep them in sync.
Now, another solution would be to only update the `configure.ac` version and
then use a script that converts this version to a `LIBUSBX_API_VERSION` number
(or do the opposite and update `configure.ac` from `LIBUSBX_API_VERSION`).
I sure wouldn't mind hearing what other people think...
---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/122#issuecomment-21438842
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
