On Fri, Mar 15, 2013 at 6:38 AM, Pete Batard <p...@akeo.ie> wrote: > On 2013.03.14 05:28, Xiaofan Chen wrote: >> Thinking a bit more into this, do we really need 2.0 so badly if it >> is only for a few "nice to have" API changes? I personally >> do not think so. It seems to me that this could be a testing >> branch instead. > > I don't particularly care if it's flagged as testing or experimental. > But I'd like to have some flexibility with regards to where we take > libusbx next, especially if we're going to handle hotplug, without > having people like Greg KH complaining about the smallest of changes, or > without being forced to devote a lot of time trying to find another > trick to get a new square peg fitting into an old round hole.
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. I think Linux distros will stick to 1.x for quite some time, especially if the hotplug feature can be backported to 1.x. As we have only identified a few API changes, potentially there could be more API changes needed down the road. So 2.0 will be kind of experimental or "subject to change". > With Hans meant to pick the 1.x branch after the 1.0.15 release, I don't > exactly see an issue with this. No issue for the 1.x branch. But rather issues for 2.0 users since it may subject to be changed. >> I think we should release 1.0.15 and then focus on hotplug. > > I'm planning do work on hotplug _as part_ of 2.x, on account that I > don't want to be constrained by our existing API if I find we can > integrate hotplug better by reworking it. But I'm also not going to > prevent anyone working on 1.x hotplug if they want, and I'm ready to > help them backport any hotplug code from 2.x into 1.x. It's of course > very possible that the changes between 1.x and 2.x will remain minimal, > but it's also possible that they may not. Plus, I still have some hope > to work on a proposal for a process based enum sometime this year, to > remove this annoying need we have to constantly reenumerate. Even if we > somehow agree this is what we want, I doubt it's going to sit down to > well with the existing 1.x branch... I see. Okay I think I understand your intention to work on hotplug as part of 2.x. >> We can drop 2.0 and rename 2.1 to 1.0.16 if it is agreed >> upon. > > You're not going to get my vote on that, sorry. No problem. Now I get to understand your intention > Also, if your concern is about trying to speed up our release process, I > don't really see how having or not having a 2.0 is going to matter one bit. No. That is not the intention. I am just worried a few users of 2.0 will get frustrated if we release as planned -- very soon after 1.0.15. 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? During the discussions of hotplug, there may be more places to optimize the API and introduce new API changes if necessary. -- Xiaofan ------------------------------------------------------------------------------ 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
