commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [VOTE] [math] top-level package name
Date Thu, 21 May 2009 13:19:55 GMT
Jörg Schaible a écrit :
> Phil Steitz wrote:
> 
>> Niall Pemberton wrote:
>>> -1
>>>
>>> IMO breaking compatibility should be decided on a case-by-case basis
>>> for components. For the widely used variety such as lang, logging,
>>> collections etc then I agree lets avoid jar-hell and not do it. But
>>> for other components that are not so widely used then such as Math I
>>> think its better to minimize the pain of upgrading for the user.'
>>>   
>> I keep going back and forth on this.  I agree strongly with the
>> "minimize the pain" objective, which is why I have been pushing to keep
>> the incompatible changes to a minimum (which we have largely
>> accomplished).  For me personally (with user hat on) it would be easier
>> if the package name did not change.  I guess what it comes down to is
>> how many users will actually experience the "jar hell" scenario with
>> [math] vs. *every* user having to change all of their imports to upgrade.
>>
>> Sorry to do this, but on reflection, I think no change is likely to be
>> the pain-minimizing alternative, so I am changing my vote to -1.
> 
> Guys, you know what you do? Actually it was already reported to the list
> that some projects already faced the incompatibility problem even with

One funny fact is that in the project for which problems occurred the
team prefers to keep the old name, despite they have already been bitten
by a 1.2 vs 2.0 jar issue.

I agree with both Niall and Phil that few users will be affected. I
guess most people using [math] do it directly, not from several
dependencies paths. The project I cited does this and the jar issue was
fixed easily once it has been spotted two different versions were in the
classpath.

> math. With you veto you simply tell them "it's your problem, but we don't
> have a solution for it either". That's what I would call a complete show
> stopper.

Both options can be considered rude for users. Some would not understand
why the name is changed and complain, some would not understand why we
would not prevent jar hell and complain too. There are no good
solutions, let's hope OSGi will become mainstream before math 3.0.

> 
> If somebody really want to migrate to newer math, he can simply search and
> replace every org.apache.commons.math to org.apache.commons.math2 and will
> then face the locations in the code where he has actually to adjust
> something. However, he must not fear that due to his switch some other 3rd
> party dep will no longer operate. With your scenario, he's simply out of
> the game.

This is not as simple. There are incompatible changes. Most changes are
not very difficult to understand and correspond to simple packages
reorganizations or renaming. However, there are also a small set of deep
modifications like the new decomposition and the reorganized
optimization frameworks. Users of these packages will have to learn the
new API and change their code, regardless of the name of the top level
package being changed or not.

Luc

> 
> - Jörg
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message