<added Greg to the CC, as I don't think he is on the list and he will want to know about this>
Hi, On 09/25/2012 01:41 AM, Pete Batard wrote: > OK, since I'd like to use the 1.1 version change as an opportunity to slide > in a couple more API changes (set transfer codes to negative, as well as #21, > and possibly libusb_strerror), but I doubt people will want to wait a week or > so, we might as well try to go with a 1.0.14 that reverts bMaxPower. Thanks! I believe that reverting the bMaxPower change and doing a 1.0.14 quickly is the right decision. I now realize making the bMaxPower change in a stable API/ABI series clearly was a mistake, and one I'm just as responsible for as you, since I acked that change! > This will occur without RC, Ack. > and, unless somebody else but me wants to take on themselves to maintain a > 1.0.x branch, may be the very last release of the 1.0 branch. Here I disagree with you (as you probably expected). I can understand the desire to fix various API issues, and to get rid of having to be compatible with the original libusb, but a soname change, even if done in a way that the result is parallel installable comes at a large price, not for us as libusbx developers, but for our users. As some apps start moving to the new API and others stick for a while with the old API Linux distributions will need to either have both, or patch apps themselves, and both require a significant amount of work from the distros, multiplied by the amount of distros. So an API/ABI break causes a large cost (in time) for our users and should not be done lightly. Also we must get it right in one go as we certainly don't want to be changing the API/ABI again in a few months from now and then again, etc... Summarizing: 1) I'm with you on doing an API/ABI break, and doing it soon, but I would like to do it right in one go, so not have both a 1.1 and a 2.0, but only 1 (don't care about the number) and include all changes in one go. 2) Doing it right in one go means making a list of desired changes, getting all of them in place in git-master (I'm willing to maintain a 1.0.x branch while we are doing that, assuming you can help with the windows side a bit), and then doing a new release. So for the list of desired API changes, for 1.1 you've planned AFAIK: 1) The bMaxPower change 2) Make transfer status error codes negative 3) Use size_t instead of int in transfer functions And for 2.0 we want: 4) Allow for functions which currently return / take a fd, to also take a windows "handle" 5) hotplug support 6) ?? Looking at the list for 1.1, although they are all nice to have, none of them to me is worth the cost of an ABI/API break. So I would really like to stay us with 1.0.x for now, until we do a 2.0. I know you (Pete) really want to move forward with all this stuff. So I suggest to create a 1.0.x branch after the 1.0.14 release, which I will maintain (*), and then you have your hands free to start working towards a 2.0 release on git master. > Unless there are objections, expect that to occur in about 22 hours or so. No objections from me on a 1.0.14 release with the bMaxPower change reverted. Regards, Hans (*) I will need help from you on building windows binaries for the 1.0.x releases ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
