On 2013.05.18 11:05, Hans de Goede wrote: > There are 2 separate things being mixed here, one is the version number > for the tarbal (and reported through the libusb_get_version call), > and the other is the soname (in Linux terms), or in other words our > ABI major version.
OK. > I agree that adding hotplug warrants using 1.2.0 for the > next version. But I disagree that we should break ABI here! In the absolute, I'd be with you. But we have ep_comp and other stuff that warrants ABI breakage, and we really should encourage people to use the version of the library we want to maintain (the one that has the API+ABI fixes) rather than tell them: "You should feel absolutely entitled to use libusb 1.0, with all its defects and non intuitive quirks, for the next few decades, because if there's one thing we sure have plenty of, it's time to maintain duplicated features and obsolete APIs on account that you don't want to plan on your app dependencies needing an ABI/API upgrade in the normal lifecycle of your software." Instead, I propose we go with this: "We're all in this together and just like yours, our development resources are limited. From time to time, we believe that, as an app developer, it's better for you to upgrade API/ABI to ensure that you and your users get the library you deserve. Now, if you don't want to upgrade, that's fine and you can still use the old library for as long as it's going to work without us dedicating resources to maintaining it. But we are moving our development to the new version from now on, and new features/fixes are meant to happen there from now on." > We can > call the next release 1.2.0 and still keep the ABI (and thus soname > under Linux). In that case, if 1.2 cannot break the ABI, and since I believe we will be much better off fixing the ABI while only maintaining one version of the library, I'm gonna vote for going 2.0 ASAP, so that POSIX gets to use the fixed ABI. > Most libraries don't break ABI when bumping the minor, they add ABI > but never break it. As you rightfully pointed out, I didn't realize that. In that case, a major bump, to upgrade the ABI, is what I'm after => 2.0. > I've been in the Linux distro "business" for a long time now, and > there is a HUGE cost to ABI breaking library releases. The only cost I see is for proprietary software (which, and I'll be crystal clear about this, I do not give a damn about on account of having spent the last 20 years finding it did a lot more damage than good for its users) as well as developers who somehow think that software is something that can reach a "finished" state and does not need regular maintenance and/or involvement. In this day and age, if you either produce proprietary or don't plan to update your software source according to how the surrounding microcosm evolves, then you're going to do a great disservice to your users. As such, but I will stress that I speak only for myself here, I'm not going to have much interest trying to be agreeable to you and your development process. But of course I am open to examples of said cost that doesn't involve any of the categories above, especially as what we'll be requiring developers to go through here, is a minor upgrade process of their software (thus I also fail to see the HUGE part). Note that I do have some sympathy for package/distro maintainers. But then again, I would say that dealing with multiple libraries and updates is also supposed to be part of their job. > And almost > always the old and new version will need to be maintained in parallel > for a long time. For example gtk+ (aka gtk-1.0) is still around Ever stopped to ask why? Could it be because proprietary software developers (or proprietary app users) as well as others who couldn't be bothered to upgrade their source, found a sympathetic ear to their (selfish) plea? You also have to compare apples with apples. The proposed change from libusbx 1.0 to libusbx 2.0 will require _very_ little work from an app developer to follow. I doubt the 1.0 to 2.0 of gtk was the same. Besides, I could turn that around by stating that if everybody wasn't so irrationally scared of breaking ABIs to introduce _gradual_ changes, maybe users of said libraries would cease throwing their arms over their head every time there is such a change, because it is meant to bring an unnatural accumulation of changes, hence a lot of work. Not sure how many API calls gtk defines, but I'm pretty sure it's a heck of a lot more than what we'll ever have in our library. > So iow doing an ABI breaking release means maintaining 2 trees, > the 1.0.x tree, and the new tree, whatever version we give it. Not the way I see it. > But we want to cleanup a lot more then just the ss ep comp stuff, > like sort out how to change our poll abstraction, so that it can > be used with windows handles too. Believe me, it will be some time before we get to poll abstraction. Also, see above for gradual ABI changes that doesn't need to look back, because it really shouldn't have to. > As said before I've no problem with starting a 2.x branch, and > doing ABI breaking API cleanup work there. I'm however very much > against doing an ABI breaking 1.2 release, shortly (relatively > shortly) followed by a 2.0 release which will break ABI again, > then we will likely end up maintaining 3 trees, which is a > way to high price to pay for a few cleanups / API improvements. Again, why, apart from principle, do we want to maintain 3 trees? Whose interests will that actually serve? The way I see it there should only be a limited transition period, as we move to the next version, and the oddball fix for the old version so that it runs. No new features, no backport of bugfixes. > And let me also try to debunk the myth that apps will simple > move to the latest version, so we can stop supporting the older > trees soon-ish. I just did a "repoquery -q --whatrequires libusb" > which gives me all the packages still requiring the old 0.1 > libusb (so libusb-compat now a days), and there are 86 packages > in Fedora still using this! I've attached a log file with the list And the amount of work we (or rather libusb) has been putting into libusb-compat sure has been staggering. In the 4 years I've been around, I have only seen the odd bugfix, and it didn't seem such a time sink. Moreover if we were to go with my proposal (not introduce hp and BOS/ep_comp in 1.0, but do that in 2.0 as well as fix some designations), and have a compat layer (which isn't really part of my plan, but that I can throw in for the same price), it would hardly be hell to maintain. Also, let me clarify this once and for all: I do not believe that app developer will magically upgrade. I am well aware that, for whatever reason, some will not. All I am saying here is that I consider that it is foolish to try to devote our time to try to satisfy these people, because if they really want what is best for their end users, by all means they should try to upgrade when convenient. And I have yet to see a justification for not upgrading an app in a reasonable timeframe (months) that held much ground. But at least, your statement allows me to make a point I also wanted to make: the more you encourage people to stick with obsolete software and imply that it's OK to do so, the more they'll do. I wonder how many 0.1 based apps you'd have to maintain _today_ if libusb had left 0.1 die its natural death, by not bothering with a compat layer... Finally, as far as I know, the recent switch to libusb/libusbx 1.0 from libftdi, and as a result openocd, has meant improved performance there (though I believe this was mostly on Windows). So tell me again how not having apps move to the latest, or taking forever to do so, is actually beneficial for the *end users*? > I'm afraid that this is the price we pay for success, libusb is > a successful, widely used lib, which means we need to maintain > older versions for a long long time ... I disagree. We think we need to maintain older versions, but we actually don't. Especially if libusb is a successful widely used lib, and FLOSS, we can afford not to, by letting others, who appear to believe they have a valid reason to keep using software that has pretty much been declared obsolete, to do that work themselves. > I'm not adverse to change, as said before I'm fine with branching of > 1.0.x (or 1.2.x if we decide to bump the minor because of hotplug), > with you taking care of master, with all the API cleanups we want, > with master to eventually become 2.x, but with no ABI / API stability > promises until the official 2.0.0 release. > > And I'll maintain the 1.0.x branch, for as long as needed. Well, as long as there's no BOS/ep_comp in 1.0, I would be OK with that (I don't really care about introducing hp in 1.0 since it doesn't break the ABI). The other advantage of not having BOS/ep_comp there is that we no longer have to worry about BSD breakage, which is nice. We can just let BSD catch up with our next API. > What I'm against is having a 3th branch which is somewhere in the middle, > that is just creating a lot of extra work for very little gain. It only creates extra work if we decide to devote our resources to older branches which, IMO, serves nobody: not our users, a lot of whom are going to get stuck with an app that is lacking functionality, not app developers, who are lead into a false sense of security that using obsolete software is OK, and not ourselves, who have to stretch our resources. > So yes, lets cleanup our API, but lets do all the cleanups we want, not > just a small set of them. Disagree. All software needs the ability to go through gradual change. As hard as I look, the idea that libraries should somehow be an exception to that seems artificial. > in the mean time I would like to not only add > bugfixes to 1.x.y, but also new functionality, even that sometimes > means using a less then ideal API. Again, I'm not adverse to new functionality in any branch, so long as it doesn't require having that functionality duplicated in completely different manners in different branches. > As long as we don't agree on this I won't add it to my darwin-integration > tree, as I want to keep that ready for pushing to master. > > Once I've something which I think is ready for review / testing I'll > publish it in a separate branch and ask for more feedback. Then let me get started on 2.0 then, with BOS (in the manner you proposed, unless I can think of something better) and ep_comp (in the descriptor). And to demonstrate that this isn't such a big deal, I'll try to have something a branch up with that by next week. Regards, /Pete ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
