On Tue, 2014-01-28 at 00:20 +0000, sebb wrote: > On 27 January 2014 22:46, Oleg Kalnichevski <[email protected]> wrote: > > On Mon, 2014-01-27 at 15:32 -0500, Gary Gregory wrote: > >> The first thing I'd like to suggest is avoiding the term 're-spin' in the > >> name of the component. To me re-spin means to retry a release. For example, > >> I cut an RC1, problems are found, so we need a re-spin to an RC2. Since > >> this is a different component, I'd just call it 'HttpClient for Android', > >> nice and simple. But this may not matter in the end because... it sounds > >> like 4.0 and 4.3 are not binary compatible (BC). > >> > >> So let's start with that, is that so? I'm looking at our site and I cannot > >> find reports like Clirr and on so. Granted in the case of HttpClient I > >> would expect a Clirr of 4.3.2 vs. 4.3.1, which would not tell me anything > >> vs 4.0. Looking at the release notes, it looks like there have been of API > >> changes that break BC, for example from 4.1 to 4.2. > >> > > > > All releases of HttpClient 4.x are backward compatible with 4.0 > > > >> Over in the Apache Commons project, the general guideline is that when you > >> break BC, you use a new package name and new Maven coordinates. See lang -> > >> lang3 and pool -> pool2 for example. If the BC break is > >> > >> If you do not do this, you are creating jar hell. > >> > > > > Jar hell on Android has already been created for us. > > Indeed - the bundled version should either have been given a new > package name, or it should be possible to upgrade it. > > >> A classic jar problem is if I depend on a third party jar that depends on > >> HC 4.0, then I cannot write my app to anything else but 4.0. If HC 5 is in > >> a new package, then I can happily use HC5 and the guts of the third party > >> jar can happily use HC4. Yes, they would not be re-using the same caches > >> for example but at least there would be no surprises. > >> > > > > This is a completely different situation. This is not a new version of > > HttpClient. It is a port. Its main goal is to provide a version of > > HttpClient compatible with Android. > > One way to be compatible is to use completely new package names. > However that has some costs for existing apps. > > On the other hand, there are also costs for using any half-way house > that is not compatible with standard HC4.
_Nothing_, absolutely _nothing_ can be compatible with standard HC4 in Android or any library compiled against it. This is like being very much concerned about dental hygiene of a corpse. We can either provide a half-way house or do nothing. > >> > >> Adding copies of a bunch of classes with an HC4 postfix seems worse (to me) > >> than another copy of HC in a new package. > >> > > > > By moving classes to a different package we would end up creating a > > pointless fork _both_ incompatible with the version shipped with Android > > and the stock 4.3 version. It just makes no sense. > > If you take an existing application running on the current HC4, it > cannot currently run on Android because of clashes with the HC4 > classes that are included in the Android OS. However, if the HC4 > classes were shaded, then the app would surely work OK on Android - it > would effectively be a different HTTP library. > > But that can be done by the app developer easily enough - there is no > need for the ASF to produce a shaded jar. > So, you are suggesting that the best course of action is to do nothing? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
