Hi, On 05/18/2013 01:31 AM, Pete Batard wrote:
On 2013.05.17 14:43, Hans de Goede wrote:
<snip>
Now, if you tell me that, no, we shouldn't really change the major there, and that updating the minor would do, then I'm going to touch what I am really after here: Why the heck do "we" seem so hell bent against simply introducing 1.1 for this and the other stuff, and then declaring that 1.1 is where libusbx happens now. This is even more true as, with it being a game changer, and even if it doesn't break the API, hp's logical place is in 1.1, not 1.0.
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. I agree that adding hotplug warrants using 1.2.0 for the next version. But I disagree that we should break ABI here! We can call the next release 1.2.0 and still keep the ABI (and thus soname under Linux). > So here we are, with a golden opportunity to sort everything that's not
experimental and that we really oughta sort, such as USB 3.0, hp, MaxPower, ctx removal and probably a couple other stuff, but we're not going to take it because you say that 1.x is off limits? Why? What can possibly be the reason that makes you not to want to break from 1.0 ever, rather than, like every other library seems to do out there, bump the micro once in a while, and let the previous version die a slow yet deserved death, with thanks for the ride.
Most libraries don't break ABI when bumping the minor, they add ABI but never break it. I've been in the Linux distro "business" for a long time now, and there is a HUGE cost to ABI breaking library releases. 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, while we've 10 years of gtk-2.0 behind us, and 2 years of gtk-3.0! Also notice there have been 8 years between gtk-2.0 and gtk-3.0 and the latest gtk-2 release, gtk-2.32 is fully backward ABI compat with gtk-2.0 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. 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. 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. 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 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 ...
No matter how I look at it, switching our development focus to an improved 1.1 is really the best logical solution here. I would go further, with saying that if we are afraid of embracing such a change, then there's something quite wrong with our development model. Yeah, this means another libusb in /lib, and developer having to make a choice. Big deal. As you may guess, I'm starting to have my fill with this let's not evolve the API outside of major, _EVER_, policy. We're developers. At which point did we take a wrong turn and become so adverse to evolution and change?
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. 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. So yes, lets cleanup our API, but lets do all the cleanups we want, not just a small set of them. Which means it will be a while before 2.0.0 comes around, and 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.
So my plan forward with the BOS / Endpoint Companion USB 3.0 descriptors is too merge Pete's patch into my darwin-integration tree, with the part I NACK-ed above fixed using the solution I suggested above.I'd rather you didn't.
I hope the above explains why I still believe this is the best way forward for 1.x.y, and I'll continue working on this. 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. Regards, Hans
0xFFFF-0:0.3.9-7.fc18.x86_64 ardour-0:2.8.16-1.fc18.x86_64 avarice-0:2.12-2.fc17.x86_64 avrdude-0:5.11.1-2.fc18.x86_64 barry-0:0.18.3-3.fc18.x86_64 barry-libs-0:0.18.3-3.fc18.x86_64 bluez-0:4.101-6.fc18.x86_64 bluez-hid2hci-0:4.101-6.fc18.x86_64 dahdi-tools-0:2.4.1-6.fc18.x86_64 dfu-programmer-0:0.5.4-4.fc18.x86_64 digikam-0:3.2.0-1.fc18.x86_64 digitemp-0:3.6.0-7.fc18.x86_64 flashrom-0:0.9.6.1-2.svn1639.fc18.x86_64 garmindev-0:0.3.4-5.fc18.x86_64 gnokii-0:0.6.31-4.fc18.x86_64 gnomad2-0:2.9.6-4.fc18.x86_64 gnupg-0:1.4.13-2.fc18.x86_64 gnupg2-smime-0:2.0.19-7.fc18.x86_64 gpsbabel-0:1.4.4-1.fc18.x86_64 hamlib-0:1.2.15.3-1.fc18.x86_64 iguanaIR-0:1.0.3-1.fc18.x86_64 isight-firmware-tools-0:1.6-3.fc18.x86_64 kdebase3-0:3.5.10-25.fc18.x86_64 lcd4linux-0:0.11-0.5.svn1143.fc18.x86_64 lcdproc-0:0.5.6-2.fc18.x86_64 libapogee-0:2.2-8.fc18.x86_64 libconcord-0:0.24-1.fc18.x86_64 libftdi-0:0.20-2.fc18.x86_64 libftdi-c++-0:0.20-2.fc18.x86_64 libgphoto2-0:2.5.2-1.fc18.x86_64 libhid-0:0.2.17-12.fc18.x86_64 libhid-python-0:0.2.17-12.fc18.x86_64 libifp-0:1.0.0.2-14.fc18.x86_64 libnfc-0:1.7.0-0.4.rc7.fc18.x86_64 libnjb-0:2.2.7-3.fc18.x86_64 libnjb-examples-0:2.2.7-3.fc18.x86_64 libnxt-0:0.3-5.fc18.x86_64 libphidget-0:2.1.8.20120912-1.fc18.x86_64 librfid-0:0.2.0-6.fc18.x86_64 libsigrok-0:0.2.0-1.fc18.x86_64 lirc-0:0.9.0-10.fc18.x86_64 mrpt-apps-0:0.9.6-2.fc18.x86_64 mrpt-base-0:0.9.6-2.fc18.x86_64 mrpt-bayes-0:0.9.6-2.fc18.x86_64 mrpt-detectors-0:0.9.6-2.fc18.x86_64 mrpt-graphs-0:0.9.6-2.fc18.x86_64 mrpt-graphslam-0:0.9.6-2.fc18.x86_64 mrpt-gui-0:0.9.6-2.fc18.x86_64 mrpt-hmtslam-0:0.9.6-2.fc18.x86_64 mrpt-hwdrivers-0:0.9.6-2.fc18.x86_64 mrpt-maps-0:0.9.6-2.fc18.x86_64 mrpt-obs-0:0.9.6-2.fc18.x86_64 mrpt-opengl-0:0.9.6-2.fc18.x86_64 mrpt-reactivenav-0:0.9.6-2.fc18.x86_64 mrpt-scanmatching-0:0.9.6-2.fc18.x86_64 mrpt-slam-0:0.9.6-2.fc18.x86_64 mrpt-topography-0:0.9.6-2.fc18.x86_64 mrpt-vision-0:0.9.6-2.fc18.x86_64 mspdebug-0:0.21-2.fc18.x86_64 multican-0:0.0.5-10.fc18.x86_64 nbc-0:1.2.1.r3-6.fc18.x86_64 novacom-server-0:1.1.0-0.7.rc1.fc18.x86_64 nut-0:2.6.5-9.fc18.x86_64 obex-data-server-1:0.4.6-4.fc18.x86_64 obexfs-0:0.12-5.fc18.x86_64 openct-0:0.6.20-5.fc18.x86_64 openobex-0:1.5-7.fc18.x86_64 openobex-apps-0:1.5-7.fc18.x86_64 openocd-0:0.6.0-2.fc18.x86_64 piklab-0:0.16.1-3.fc18.x86_64 pilot-link-libs-2:0.12.5-13.fc18.x86_64 player-0:3.0.2-21.fc18.x86_64 pyifp-0:0.2.2-6.fc18.x86_64 r5u87x-firmware-0:0.2.0-4.a9b2171d762b.fc17.x86_64 sane-backends-0:1.0.23-7.fc18.x86_64 sane-backends-drivers-scanners-0:1.0.23-7.fc18.x86_64 sane-backends-libs-0:1.0.23-7.fc18.x86_64 serdisplib-0:1.97.9-3.fc18.x86_64 serdisplib-tools-0:1.97.9-3.fc18.x86_64 tucnak2-0:2.31-6.fc18.x86_64 urjtag-0:0.10-3.fc18.20111215gite1a4227.x86_64 usb_modeswitch-0:1.2.5-1.fc18.x86_64 usbsoftrock-0:1.0.2-4.fc18.x86_64 vfrnav-0:20130429-1.fc18.x86_64 vfrnav-utils-0:20130429-1.fc18.x86_64 xfce4-cellmodem-plugin-0:0.0.5-11.fc18.x86_64
------------------------------------------------------------------------------ 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
