Hi, tl, dr: Doing an ABI/API breaking 2.0 has my support, but lets try to avoid doing another ABI/API breaking release soon after that.
On 09/27/2012 12:36 AM, Pete Batard wrote: > 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. Yes, but those are just our developer users, we also have dsitro-users / packagers. And if one interesting application is in the latest and greatest group and his app only works with the latest libusbx, then the distro will need to package 2 versions of libusbx (3 if you count 0.1 compat), now 2 versions is perfectly fine. Things become trouble some when we burn through ABI/API breaking releases so quickly that a distro ends up having to package 3 or more versions. > > 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. I fully expected you wanting to go for a 2.0 full throttle which is why I offered this: > 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. I'm not that worried about maintaining a 1.0.x branch costing me too much time, and don't forget I can work on this as part of my day job (to certain limits). > >> 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. We could do a number of 1.9.x 2.0-pre releases, ie: 1.9.0 1.9.1 1.9.2 1.9.90 1.9.91 1.9.99 Before doing 2.0.0 and make it clear that these are development versions and make clear that we reserve the right for further API/ABI breaking changes to land before we do a stable 2.0 release, actually I would very much prefer us to do that! > 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 That would work too, my only worry is the hotplug stuff, I think we should at least do an API design for that on paper / evaluate the API from the existing hotplug branch and make sure the 2.0 API is prepared to add hotplug later without breaking ABI/API. > 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 See above >> 6) Add a uint32_t stream_id to struct libusb_transfer for USB-3 bulk > Sounds like API breakage => IN Note for now we can just add the field without using it, as currently none of the OS backends support bulkstreams, but once we start supporting bulkstreams we will need this. *** important *** : And we should also add a stream_id parameter to libusb_fill_bulk_transfer > 7. Remove the use of interface in libusb.h, as it's a C++ headache, > which we have just been reminded of (great timing!). Ack. > > 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. Ack. As a one last note, we should probably also rename the header file, etc, from libusb to libusbx for the 2.0 release. Regards, Hans ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
