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
> <gil...@harfang.homelinux.org> 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" and
>>>> "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 easy
>>>> 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: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
