On Mon, Sep 24, 2012 at 09:12:56PM +0200, Hans de Goede wrote: > Hi, > > On 09/24/2012 08:50 PM, Greg KH wrote: > >On Mon, Sep 24, 2012 at 08:36:11PM +0200, Hans de Goede wrote: > >>Hi Greg, > >> > >>On 09/24/2012 05:07 PM, Greg KH wrote: > >>>On Mon, Sep 24, 2012 at 03:52:55PM +0200, Hans de Goede wrote: > >>>>Hi, > >>>> > >>>>On 09/20/2012 11:42 PM, Pete Batard wrote: > >>>>>Hi, > >>>>> > >>>>>It with pleasure that I would like to announce the release of libusbx > >>>>>1.0.13. This version brings the following notable changes: > >>>> > >>>>The Fedora packages for libusbx have been upgraded to 1.0.13 now. > >>> > >>>How did you handle the usbutils breakage? > >> > >>I did not handle it at all, as I was not aware of it. Now that I'm I'll > >>file a bug against usbutils and advice the maintainer to add the > >>necessary #ifdef-ery to keep it building. > > > >So, you are going to force me (hint, I'm the usbutils maintainer) > > I know you are the usbutils maintainer. > > >, to > >change my code because libusbx broke their API here? > > Force you, no, forcing you to do anything is (luckily) not within my > power. But I can surely ask you nicely to change your code. > > >That's what other > >distros have already tried to tell me earlier today, and I'm going to > >push back hard and say that it is a bug in libusbx instead. > > I can certainly understand that from your pov this seems as a libusbx > bug. Pete has already tried to explain his reasoning for the change > in his mail to you. And it seems that the problem is that there is > a difference of opinion here on priorities, Pete beliefs following > the USB spec and fixing a historic mistake is more important here, you > belief that API compatibility is more important. > > I myself am somewhere in the middle here, I did not think that the > change Pete suggested would be a big deal (how wrong of me), so I agreed > to it. However your reaction shows that API compatibility is a big deal, > and in general I agree with that. So lets try to move forward with this. > > I see 3 possible solutions: > > 1) Revert the change, and do a 1.0.14 release with just that change > right away, before anyone starts depending on the new name That would be a good first step, given the fall-out I've already gotten from the distros who have tried to incorporate 1.0.13 into their build systems. > 2) Adapt usbutils to work with both versions of the API, as is suggested > in the release announcement. But given what you said above I guess you're > unwilling to do that ? Why not bump the .so name of the library if you are changing the API? How hard is that concept to people? > 3) Go with the anonymous union solution discussed before, and do a 1.0.14 > release with that change right away. That's fine with me as well, and solves the .so name issue. > However we solve this I've learned from this to take API compatibility as > something very important, and the next time we discuss something like this > I will not only vigorously defend ABI but also API compatibility, and I > promise that I will do my very best to make sure that the libusbx-1.0.x > series will stay fully ABI and API compatible for all future releases! Thank you. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
