On 2013.03.15 00:55, Xiaofan Chen wrote: > I see. My point is that not many users may want to go with > 2.0 since it offers not much benefits compared to 1.0.15 > but rather inconvenience to them.
OK. I have a somewhat different opinion on that. I can see why some people may think that removing the use of "interface" and other changes, that taken in isolation could be labelled as minor, is no reason for an upgrade. But the idea is that, besides the fact that we're really not forcing anybody to upgrade, these minor changes will actually improve the lives of other developers. Someone, somewhere, IS going to run into a conflict when they try to develop their software because we have an API that uses 'interface' as a parameter, and in some circumstances this is a reserved keyword. Why of why should we be reluctant to help these developers? So my problem is, if we go by the majority feel as well as trying to limit perceived inconveniences, then the outcome will most certainly be: "screw whoever needs to use libusbx in a situation where 'interface' conflicts - why should I have to modify MY code to help these guys? Instead, couldn't libusbx just shelve all these minor API changes and stop dangling the prospect of inviting ME to upgrade my libusbx dependencies _eventually_?" The thing is - we've been patient. We've been sitting on these changes for quite some time, but there comes a day where we have to say "Sorry pal - if you went into software development with the expectation that the landscape you rely on isn't going to evolve, you must have missed your true calling as a chartered accountant. Software development is anything but same old same old.". And personally, I can't fathom why a software developer worthy of this name should be reluctant to even most minimal of changes if the persons who made that change indicate that they believe it's for the best. If they are, it means that users of their software are going to be missing on innovation (or bugfixes) eventually, and you can't be serious about software development if your first priority isn't to provide what is best for your users in the long run... And yes, that implies moving along with your dependencies as they evolve or switching to new, better ones or using updated tools and methodologies, etc. If the above is _perceived_ as an inconvenience to some developers, then I'd say that it's probably a good thing. At the very least, it should help avoid software development complacency. > I think Linux distros > will stick to 1.x for quite some time, especially if the hotplug > feature can be backported to 1.x. Which is absolutely fine. We're not forcing anybody to switch from one day to the next. Eventually however, for users' sake, I sure hope they will keep a place for upgrading. > As we have only identified a few API changes, Mostly due to lack of time filling the blanks. I hoped it was fairly obvious that whatever's on the wiki is far from final at this stage, and is still pretty much a quick jolt down. > there could be more API changes needed down the road. Not could. Will. Software must evolve becasue if it doesn't, you're doing it wrong. Yeah, that applies to APIs too. > So 2.0 will be kind of experimental or "subject to change". And that is why we have an easy way to let developers identify API compatibility issues, through LIBUSBX_API_VERSION in libusb.h. This wasn't an entirely innocuous addon you know... > No issue for the 1.x branch. But rather issues for 2.0 users > since it may subject to be changed. See above. Libraries are no special case. Software has to to evolve. But again, we're not going to force anyone to evolve at the same pace we do. > One possibility is to go to the 2.0 branch and work on hotplug > but without the release of 2.0, i.e., merge 2.0/2.1. How do you > like the idea? Do you really believe I can subscribe to the idea of keeping releases under wraps, when lack of releases and utter disregard for RERO from libusb is the reason I joined the libusbx fork? > During the discussions of hotplug, there may be > more places to optimize the API and introduce new API changes > if necessary. Yep. Which can be done with 2.1, 2.2, 3.0... Luckily for us, it's not like integer numbers are finite... ;) This being said, I feel like, once more, I need to kill in the bud the recurring idea that, somehow, I'm going to push for a new major libusbx release every other 3 months or so. I can't shake the feeling that some people around here are irrationally worried about that. Even if I really wanted to, which I don't, I'd never have enough spare time to go into that fast a release cycle. Regards, /Pete ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
