commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: [math] roadmap for 2.X and 3.0 ?
Date Wed, 24 Nov 2010 15:15:40 GMT
Ok, so if you guys go to a 3.0 version which breaks compatibility,
then I'd suggest you do the package/artifactId "switcheroo".  Note,
this is not technically changing the name of the project.  It's merely
a way to avoid "jar hell" (as has been discussed numerous times).
Yes, it will involve a bit of a migration for users, but since you're
binary incompatible, they're already having to do some migration and
find/replace the package name is a very easy fix (as a starting point
for them) for them.

On Wed, Nov 24, 2010 at 10:09 AM, Luc Maisonobe <> wrote:
> Le 24/11/2010 15:34, James Carman a écrit :
>> If you break compatibility, then the advisable thing to do is change
>> the package name (and artifactId, etc.).  Now, if we can be almost
>> certain that there would be no case that you wouldn't have a situation
>> come up where two different, incompatible versions of math would be
>> required on the classpath (you guys can't think of a situation where
>> one project might use two different libraries that use two different
>> version of math?), then I would think it would be acceptable to not
>> change the package name.  I obviously find that assertion to be
>> suspect.
> I already know two such projects.
> The first one uses [math] and a lot of other libraries and packs
> everything in a big library provided to several different teams. These
> teams are not in sync and despite the project manager would probably
> very much like to have them use one version only, I'm sure it will not
> happen before the final freeze of the product. At one time, there will
> most probably be both math 2.2 and math 3.0 embedded in this single big
> library.
> The second project uses Orekit (which relies on [math]) and also uses
> [math] directly. Orekit does track [math] evolution closely (the ODE
> refactoring stuff is the next big change it really needs) but the top
> level project does not necessarily wants to switch to the new
> optimization stuff soon, so they may also use both versions.
> Luc
>> On Wed, Nov 24, 2010 at 9:27 AM, Gilles Sadowski
>> <> wrote:
>>> Hi.
>>>>> [...]
>>>>> The name change is an option only if we can reasonably expect that
>>>>> applications would use both "math" and "math3".
>>>> No, the sole purpose of such a change is to avoid jar hell for
>>>> applications that do not use fancy loading mechanisms like OSGi.
>>> Why, "no"?
>>> "Jar hell" is indeed what I meant: When some application has e.g.
>>> "commons-math-2.2.jar" and "commons-math-3.0.jar" in the classpath
>>> with the base package being "org.apache.commons.math" for both.
>>> A name change allows "math" (classes at vesion 2.2) and "math3" (classes at
>>> version 3.0) to coexist.
>>> However, this (implicitly) suggests that both can be used, whereas, as you
>>> say below, old releases immediately become unsupported.
>>> [And we come back to the arguments that were laid out last time the name
>>> change was proposed: namely, after "math3", there will be "math4", etc.
>>> All library projects could do that, and a version number would become
>>> useless. Since they don't, there must be drawbacks ;-).]
>>>>> But that would mean that we
>>>>> can promise to the developers of those applications, that both "math"
>>>>> "math3" will be supported in the future. I don't think there are human
>>>>> ressources to do that (and, as you pointed out, it is not a nice and
>>>>> job).
>>>> Yes. Once a release is done, we suggest people finding bug in a previous
>>>> version to first check if it is still present in the last one and we fix
>>>> it in this version. I am not aware of any real case for which we would
>>>> have published a fix for an old version.
>>> Then, a name change is not necessary. [It is even harmful from a visibility
>>> ("marketing") point-of-view.]
>>> Regards,
>>> Gilles
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message