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... We *will* deviate in an incompatible fashion sooner rather than later. To me, trying to delay this inevitability doesn't seem very productive. 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. 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. > IMHO in this case maintaining ABI compatibility trumps your concerns > about these strings. 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. Regards, /Pete ------------------------------------------------------------------------------ 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
