Responding to Hans' replies from 2 days ago. I'll try to be brief. 1. There are 2 group of developer-users of libusb(x). The ones who want stability, but also seem to have been just swell with a libusb that didn't see releases in years, and the ones who want to go with the latest and greatest as soon as it's released (as Greg's inbox seemed to confirm). Two very different crowds.
2. I fail to see how bumping APIs, to try to satisfy the latter group is going to hurt the former much, especially if it helps reach our goal of comprehensive cross-platform generic USB access faster, which our users should also want (though they may want to get there at different paces). If reaching that goal takes multiple iterations of our API, I firmly believe we should have the freedom to do so, though you will realize that I'm also not keen on adding more than we need (but I do see fixing deviation from the specs, no matter how minimal, as reason enough to create a version bump sooner rather than later, and use that to bring in the other API changes that were lined up). 3. Even as we try to maintain drop-in compatibility with libusb-1.0, we can count on almost none of the feature we introduce in 1.0 to be leveraged by users who are in for compatibility. Might as well split between stable and experimental then, as most projects do. 4. As Sarah also suggested, libusbx should really have been labelled libusb-2.0. Many of our users requested that we should exist in a different space from libusb-1.0, and I fully agree with that. I've grown tired enough of trying to solve "libusbx and libusb don't seem to play nicely", and I think it is high time to stop wasting so much of our resources on that, as well as trying to second guess what libusb-1.0 will or will not do. 5. I'm not going to have the scope (and I might add interest) to maintain two branches at once, and that's the reason I mentioned dropping 1.0 as far as I'm concerned. This being said: > I'm willing to maintain a 1.0.x branch Thanks. I was hoping someone would pick that up, though I'd have preferred someone new, as we are stretching our resources, and this will cause issues. > assuming you can help with the windows side a bit Should be able to do that. Also going 2.0 rather than 1.1, and trying to squeeze as many of the API breakage we had lined up is also fine, though this may require further delaying of 2.0 and a messy situation. Therefore my proposal will to not introduce any new APIs calls in 2.0, and those can be sorted out later and also not introduce any new code into 2.0, besides what's needed to handle the API breakage Now, for the changes: > 1) The bMaxPower change API breakage => IN > 2) Make transfer status error codes negative API breakage => IN > 3) Use size_t instead of int in transfer functions API breakage => IN > 4) Allow for functions which currently return / take a fd, to also take a > windows "handle" API breakage => IN, though there is a possibility we will > 5) hotplug support new API (at least from what I remember of hp phase 1) => OUT > 6) Add a uint32_t stream_id to struct libusb_transfer for USB-3 bulk Sounds like API breakage => IN 7. Remove the use of interface in libusb.h, as it's a C++ headache, which we have just been reminded of (great timing!). I'll create a wiki page or something where we can list the proposed 2.0 API changes and invite comments. We probably also want to announce that the wider audiences, and give time to the linux-usb and other mailing lists for comments. Regards, /Pete ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
