On Mon, Sep 24, 2012 at 03:20:10PM -0400, Sean McBride wrote: > On Mon, 24 Sep 2012 11:47:27 -0700, Greg KH said: > > >No, you are forcing me to change my program to have it build with your > >change, you should do it the other way around. If you want programs to > >use your library, make it so that they don't have to be changed at all. > > > >And if I'm going to be forced to change my program, and libusbx has now > >shown that they don't care about their public api, well, I might as well > >just rewrite it to remove that dependancy completly, as it's obvious > >they don't know how to treat their users. > > I hesitate to participate in this thread, as I don't like flame wars, > but a piece of honest constructive criticism: if your project depends > on libusbx (or any other project) why did you not try the release > candidates to catch this problem before release? Was the RC period > too short? Were you unaware of it?
My program depends on "libusb", which, as it seems there are now two different versions, one would think that they would at least not break backward compatibility. And yes, I was not aware of the libusbx release cycle, but I surely did not think that a library would break its API without changing the .so name of the library. To do so would be madness, don't you agree? I would ask how this library update was tested if someone didn't, at the very least, test the most common application that uses the library? greg k-h ------------------------------------------------------------------------------ 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
