Re: [Libusbx-devel] libusbx-1.0.13 has been released

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux