I'll start with some comments on distro packagers. With regards to the bMaxPower specific issue (which I understand wasn't your point, but still worth mentioning), they had what I consider 2 easy ways to address it: Apply the straightforward usbutils patch we would have provided to them as soon as they engaged us, which they could do regardless of Greg's decision, or, in case our timing didn't suit them, stick to 1.0.12 for a while. I kind of expect distros maintainers to have some capacity to apply out of band fixes when they pop up, and the bMaxPower compatibility patch, though not a bug fix, isn't that different. Besides, unless we're not doing our job properly, we're not going to find deviations from the specs every other year, so this was very much intended to be a one-off thing.
So, at least with regards to bMaxPower alone, distro packagers weren't that much of a concern to me. But with regards to your actual point, even as I have little intention to "burn through ABI/API breaking releases (...) quickly", there are 2 aspects to consider: 1. We have a huge backlog of potentially API breaking features that are a consequence of the lack of libusb releases over the past few years. Had libusb been a well oiled machine, we'd probably have had something like a 1.1 release some years ago already (it's been in trac for a few years) and would probably be looking into 2.0 right now, if not releasing it. But we haven't been in a position to get that. So we are in an exceptional state, compared to other libraries, in that we have to play a huge catchup game with our backlog. IMO, the sooner we are done with this all too painful exercise, the better it'll be for everybody. But that also means that, as much as we'd like to avoid it, users might have to contend with some of the consequences of trying to get to a much more breathable position, such as our trying to slide an API breakage without a version change on what we estimate (rightly or wrongly) to be a low impact change, so that we can avoid having users go through versions upgrades more frequently than they're going to be happy with... 2. Even if we were to issue more API bumps than everybody would like, I don't see the multiplication of APIs over a relatively short period of time as much of a threat for distro packagers: they are the one group of people who have the ability to force an application to stick to one and only one specific API/ABI, should they decide it'll make their lives easier. Do you have examples, for instance, of packages that are being maintained for both libusb 0.1 and 1.0? It sounds like a huge waste of resources to me to have spent time on package upgrade from 0.1 to 1.0, and then keep supporting both of them, let alone more than two. But maybe you are talking about the work required during the API upgrade transition period itself? If that's the case, then I don't see that as a major concern either, as, even as our 1.0 API has been stable for years, way too many apps are still relying on 0.1 and seem nowhere close to transitioning to 1.0. Therefore, I doubt we're going to require more resources from app maintainers, should we ever think that bumping our APIs twice a year is fair game. Empirical evidence seems to indicate that that established apps are unlikely to try to follow such a quick release cycle, and will skip the ones that are too close. Now, with regards to the other matters: Great, at last somebody else is proposing some rebranding and moving away from a potentially conflicting libusb space. >>> "libusbx-2.0\libusbx.h" >> "include <libusb.h>" I think we should to go all the way with our header rebranding, and use libusbx.h, even as we keep libusb_api_call(). Be it only from a support's perspective, if someone only sends us code, it may help to have some evidence that they are actually using libusbx just by looking at it, and that they has a clear intent to do so. Plus, I think the libusb guys would also be quite happy not to end up with libusbx users that got confused by the presence of a libusb.h. Besides, we are a fork. And while we of course want to make it easy for our users to switch, we also have to make it clear that we are a very separate entity from libusb. As such, we should request our users to willingly choose which one they really want to use, be it only with a one letter change in their header. Proceeding any differently seems very unhealthy to me, as it still leaves some of the uncertainty I would like to see us break free from. And yeah, this makes our own 1.0 -> 2.0 process (slightly) more difficult. But then again, the real reason for the above was our decision not to break clean from libusb when we first released, so it seems a bit of a catch 22. >> But I assume we are going to keep calling all the functions / structs >> libusb_foo and not libusbx_foo, That's the way I see it too. While I'm all for helping our users understand that they need to choose between fork and original, once we're past that, the need for code modifications should be as close to zero as possible. > BTW, I do not quite understand the current roadmap page with > regard to 1.1,0 and 1.1.1. I think they will not be materialized, > right? > https://github.com/libusbx/libusbx/issues/milestones?direction=asc&sort=due_date Yeah, I will fix that. Or you can if you want... ;) As to going 1.9 with big EXPERIMENTAL notices, I'm also all for it. Finally, with regards to figuring out some of hotplug, I'll have to dig up the 3 phase plan that we kind of talked about previously. In the meantime, this [1] is one way the initial phase (non event related) of hotplug addition can be approached. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=blobdiff;f=libusb/libusb.h;h=f5eb81110d7ef9698c6c2b1783b681a5a3fa3a2f;hp=d46c68b4512b15b06a547100d47e638766f82f0c;hb=6cb025b4c853f2c034f72e12b1ab243d9d6e2a59;hpb=f62bae968fc07aff6e7f1e77b70e10010652a0df;js=1 ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
