Hi, On 04/23/2012 12:12 PM, Pete Batard wrote: > On 2012.04.23 08:40, Hans de Goede wrote: >> I can understand you not being happy with these addons, but without them >> code compiled against Peter's version of get_version may crash, so I >> strongly >> prefer adding them (despite your concerns) > > Well, my concerns go a bit further than that. > > If we go this route it means that every time Peter wants us to implement > an half-assed solution that we shouldn't follow in the first place, he > just has to arrange a way to make an app crash when switching to > libusbx, and lo and behold, we are forced to carry it or add a > workaround. Great job forking so that we no longer have to be forced to > follow libusb's every disputable whim...
I'm not saying that we should follow every whim Peter comes up with, I'm merely pointing out that in this case we can easily make it so that we are ABI compatible with libusb-1.0.9. Which means that when we release libusbx-1.0.11 and later, with hopefully appealing features to our users we can advertise full ABI compatibility with libusb-1.0.9 making it easy for those who have not yet switched to switch. As for further ABI differences introduced by Peter lets deal with those on a case by case basis. Also keep in mind that we likely won't see a libusb-1.0.10 with possible ABI changes until 2014. I would also like to stay ABI compatible with libusb.git, but if there are ABI changes introduced there which we really don't want to mirror we can simply drop ABI compatibility as something we strife for at that point in time. > We *will* deviate in an incompatible fashion sooner rather than later. > To me, trying to delay this inevitability doesn't seem very productive. I don't mind deviating, but if possible I would like our libusbx-1.0.x API to be a superset of libusb-1.0.x, so that people can painlessly switch. > In its current implementation, as I explained, I very much see Peter's > versioning buggy as it unnecessarily breaks cross-platform, so having > something buggy that makes an application crash is not exactly > unexpected... Any application that uses Peter's versioning will have > issues when it comes to Microsoft compilers => by and large, > applications are better off NOT using it. To that extent, I think > libusbx should encourage developers to steer away from it one way or > another, especially as we have a much better versioning to provide. > Crashing or compilation errors, while not preferable, are such a way. Your making a very large hyperbole of the whole string issue here. I have to agree that Peter's git --describe trick is stupid, since when building from a tarbal (like 99.9% of all libusb users do) there is no .git dir, so git --describe does not work. Consequence -> the describe string is the empty string for tarbal builds. So we can simply always make it the empty string if we want to, and still be 100% compat to libusb tarbal builds. > Also, I don't think you guys logically considered the implications: > 1. If an originally libusb based application crashes, it's because it is > trying to use Peter's extra field. > 2. Ergo, if it crashes, it is trying to do something with regards to a > versioning element that we do not carry out in libusbx and that needs to > be modified > 3. Ergo, not having the field is likely to actually improve the > application if it forces the developer to update it, whereas keeping it > may very well silently break down the app down the line, in a more > damaging manner. For instance, the application may have used the extra > field to apply a workaround for a bug in a specific libusb version and > when ported to libusbx, this workaround will not be applied for the > equivalent libusbx version with the same bug => end users will pay the > price. Your really showing that you're running out of sane arguments here, first of all any sane version check to work around bugs will use the integer field rather then relying on string parsing, second relying on string parsing won't work with libusb itself either, because for a tarbal release both strings are the empty string there. > When trying to consider it logically, from what will benefit the > end-users rather than what will benefit application developers (but I > would assert that the prime concern of app developers should also be > what benefits end-users), I really don't see it that way. > But if there's a majority that wants the extra field, I'll have no > choice but to comply. > > My vote however would be to place a big "OBSOLETE - IF YOU USE THIS > FIELD, UPDATE YOUR APP FOR LIBUSBX VERSIONING" in there, because one way > or another, we want to alert app developers to the risks of keeping code > based on libusb's versioning when they switch to libusbx. I'm fine with marking these fields as OBSOLETE, we can even just always make the descr string return the empty string on libusbx builds, and document it is always being the empty string. Regards, Hans ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
