From: Vitali L. <vl...@gm...> - 2011-07-13 17:08:20
|
I'm not affected by this since the libusb version we use is packaged with our app. But OSes packaging libusb might have problems (in fact likely will). It's a philosophical question. My convention for my own libraries has always been: X.Y.Z Z - bug fixes. no API changes. Y - bug fixes, new features, API additions (source & binary compatible) X - bug fixes, API changes. incrementing this indicates potential binary & source API breakage. It makes it extremely easy because you know where or not you can drop in a newer version as a replacement (there's always value add in being able to do that). Also, how many users you have directly affects how much you can break expectations & have people be accepting. The more people you have, the more there is an expectation of consistency against which you have to balance making improvements. I expect that LUFA has far fewer users than libusb (never even heard of LUFA before). I'm not saying that the above should be a policy we adopt or that libusb won't be successful as a project without it or something similar. I'm just saying that this kind of consistency makes it easier on everyone (especially Linux distros) and then allows people to understand about implications a release might contain. -Vitali On Jul 13, 2011, at 9:30 AM, Pete Batard wrote: > On 2011.07.13 14:43, Vitali Lovich wrote: >> Basically libusb will have lost source & binary compatibility > > How would that affect you exactly? Can you clarify the worst case > scenario for doing it outside of a dot release for your application? > > I'm not saying that we should perform API changes in 1.0.9 or 1.0.10 > (and I'm not speaking as someone who has much weight with regards to > future libusb API changes anyway), but given the hellishly *slow* rate > of release of libusb, I kind of fail to see how modifying the next > version of your app after a libusb API change, to use the new API calls, > while telling your users to only use libusb version x.y.z or later, with > y and z not necessarily being zero, is going to be that much of a > problem. It's not like there will be much confusion about which libusb > version to use and the extra work incurred on you by this change also > seems quite limited. Also, even if you invite your end users to only use > 1.0, you can be certain that there will be some who want to use 1.1 or > 2.0 regardless, so you will have to provide an updated version of your > app eventually anyway. Or do you expect your app to use a libusb shared > library and have to compete with another app that would require the old > calls, and would be unlikely to be updated to use the new calls as yours > would be? > > I've seen LUFA break its API from one release to the next (actual > breakage, such as completely different parameters on existing calls), > but I don't remember LUFA users being up in arms about it. In fact, LUFA > seems as successful as ever. After being confronted to API breakage as a > developer (and being as annoyed by it as anyone else when it happened), > I will still say that too much is being made of API breakage, when the > key to good software is flexibility and adaptability. Requiring an API > to remain static is like requiring code to not include bugs or > limitations, or old software to be supported forever. Great in the > absolute, but unrealistic in practice. Sure, we'll try to provide code > that has as few bugs/limitations as we can make it, and APIs that remain > backward compatible if we can, but we also expect you to be able to > adapt if that isn't the case. If we don't have enough resources to > maintain 2 separate sets of APIs at the same time, just so you can avoid > updating your code, then it won't matter if the API change occurs on a > dot zero release or not. > > But right now, given the unbearably slow rate of libusb releases, you > really don't have to worry about libusb API changes occurring anytime soon. > > Regards, > > /Pete > > ------------------------------------------------------------------------------ > AppSumo Presents a FREE Video for the SourceForge Community by Eric > Ries, the creator of the Lean Startup Methodology on "Lean Startup > Secrets Revealed." This video shows you how to validate your ideas, > optimize your ideas and identify your business strategy. > http://p.sf.net/sfu/appsumosfdev2dev > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel |