On 4/23/12 13:12, "Pete Batard" <p...@akeo.ie> wrote: >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...
On principle level I agree, ie it cannot be that libusbx should be forced to do something because libusb changes something. I'm not paranoid (although they are out to get me ;-) and will give Peter the benefit of doubt why this addition and sudden release of 1.0.9 happened, we should not open the door for this kind of forced change. Having said that at times a pragmatic approach is better that a principled one. Which one is better is not yet absolutely clear to me. > >We *will* deviate in an incompatible fashion sooner rather than later. >To me, trying to delay this inevitability doesn't seem very productive. Agree. > >In its current implementation, as I explained, I very much see Peter's >versioning buggy as it unnecessarily breaks cross-platform, This is not clear to me, someone cares to educate why and how this 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. If that is the case then it sounds like it better for the application not to use this. >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. Crashing is not nice, although a fast and consistent crash with clear indication of the issue is acceptable. Compile/link and/or load error would be best. > 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. That is a very compelling reason and buys me into voting against adding those fields. Just to ensure I understand the issue, please tell me if this is correct (I've not looked at the code, all this is based on monitoring the libusb lists): There is a new function function (in 1.0.9) in both libusb and libusbx. This function takes and argument of type libusb_version, and this type has different structure in the two libusbs, namely libusb has added two fields. Is this correct? If so, then there is no code utilizing that new functionality and thus compatibility with existing code is a moot point and this seems like a perfect opportunity for to steer new development away from dysfunctional libusb project. If you want to have new functionality provided by libusb and believe that *that* project has a future, go with that. Otherwise use libusbx provided functionality. Pick your side. br Kusti ------------------------------------------------------------------------------ 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
