Hi, On 06/12/2013 01:45 AM, Pete Batard wrote: > On 2013.06.11 11:10, Hans de Goede wrote: >> I think it would be good to tag current master as 1.0.16-rc1, spin >> tarbals, etc. > > I'd prefer if we don't tag the RC-1 until next Monday, on account that: > - I'd like to keep at least a little distance between 2 major events, > such as the announcement of libusbx and libusb merging back and libusbx > getting into release mode. There's the possibility that, since libusbx > is planned to be the effective continuation of libusb, people over at > libusb may request a few things from the next libusbx release. > - It's nice to give people a few days before RC gets into effect, in > case they are working on something they'd like to see integrated, before > we freeze the addon of new features. > - It'll give us exactly 2 weeks of RC time to the officially planned > release, as per our milestones, which I think is what we agreed on for RCs. >
Ok, that works for me. I still would like to see one more feature added to 1.0.16, and this will give me this for that :) I'm talking about adding a libusb_enable_auto_detach_kernel_driver function and implementation for Linux. Rationale: 1) I believe this is what most apps will really want (libusb taking care of the kernel driver management / detach + re-attach). 2) Linux has a new ioctl now to do detach + claim-interface in one go in a race-free manner. We've discussed exporting this before and came up with a different solution, but now I believe this is a better way of exporting this. 3) This will make it much easier for cross-platform code to deal with kernel driver detach / re-attach. Instead of having compile time (or now with capabilities runtime) checks for this, and then needing to error-check the detach result on supported platform, they can simply do: libusb_enable_auto_detach_kernel_driver(device); This which will return either LIBUSB_ERROR_NOT_SUPPORTED or LIBUSB_SUCCESS, so most apps can simply ignore its return value, since on platforms where this is not supported they won't care about detaching / re-attach anyways. I don't believe this is worth slipping the 1.0.16 schedule for, so I'll try to write an RFC patch for this tomorrow. Then people can review over the weekend I can push it on Monday. Or if I fail to find time / the patch fails review in a major way, we can punt this to 1.0.17. >> I'm willing to the work for this (*), with the exception of providing >> windows binaries. > > Sounds good to me. Thanks. > >> Pete, I believe that you've a checklist for the release process somewhere ? > > Hidden in plain sight, at > https://github.com/libusbx/libusbx/wiki/Maintainers%27-Corner#wiki-RCRelease_work Thanks for the pointer. Regards, Hans ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
