On 2013.03.06 02:32, Xiaofan Chen wrote: > Right now there are still a few issues open for 1.0.15 release. I think none > of them are really critical, perhaps with the exception of #97 (64bit issue > for Mac OS X).
Yeah, sorry for not posting about the 1.0.15 release. I've been trying to gear up towards it (while hoping against odds that libusb would have their own release by that time so that we'd effortlessly picked the patches we want), but then additional stuff got added, and I also wanted to complete the CE cleanup. > For example, I myself do not think #83 and #98 are that important. I disagree with #98 being minor. Even if we haven't seen it result in an actual issue, leaving glaring warnings in a release is bad practice. Personally then, I do not want to go to 1.0.15 without a fix for it. But now that the Ext Descriptors issue is (hopefully) out of the way for good, this issue is pretty much on top of my list. Also, if you create and assign issues to be fixed to 1.0.15, then of course I'm going to be reluctant to go to 1.0.15 without fixing them. That's partially why I delayed the release again when you added the Ext Descriptors issue on that list: the more you add, the more delayed the release. This being said, here are the items I'd prefer not to go to release without: - #98, for the reason explained above - Introducing a LIBUSB_CAP_HAS_HID capability, on the model of libusb's LIBUSB_CAP_HAS_HOTPLUG. This shouldn't take too long, and I still have some hope to see libusb release their 1.0.16 between our 1.0.15 and 1.0.16, so we might as well get our users acquainted with caps from both sides. - #83, mostly because it used to be working fine, and I'll take static over dynamic anytime. Everytime I look at the backlog, I'm annoyed to be remembered that static cross compilation is broken... - Whatever critical OS-X stuff we think we need, but I haven't looked that closely at Darwin... and I sure wouldn't mind if someone could take care of posting ready-to-integrate OS X patches to the list, to speed things up there. Now, if it starts to look like we're going to delay the release again, I don't have an issue pushing #83 out of 1.0.15, and since I don't know precisely what the deal is with Darwin, I'm not too worried about pushing it out either. But I'd place the first two as must have in my book. > BTW, Nathan's idea to use 1.0.16 is to avoid conflict with libusbx > release number (1.0.10-1.0.15). So it is not really for numbering > game. And how exactly is that gonna help when we do release 1.0.16? Does libusb expect us to jump across the version numbers in the same way they're planning to do? That's utter bullshit if you ask me, as it's not gonna help our users. We're 2 independent projects - if libusb can't get over it, we damn sure will. > So I think it is good not to further delay 1.0.15 release and let's > fix the release date as stated in the milestone The best I can say is, I'll see what I can do to make the release date. However, I can't promise anything with regards to tasks from other projects taking precedence over libusbx ones (*). Regards, /Pete (*) Not to blow my own trumpet, but Rufus is already up to a quarter million downloads for 2013, so I can't entirely ignore my users there... Damn you libusb, for being so slow to release that I had to start yet another project on the side, with that project ending up being a lot more popular than anticipated! ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
