Le 24/11/2010 15:27, Gilles Sadowski a écrit :
> 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.
I put my sentence at the wrong place, sorry. The no was an answer to the
following paragraph, i.e. "we can promise to the developers of those
applications, that both "math" and "math3" will be supported in the
future". I meant: no, we don't promise that. For the paragraph above,
i.e. "we can reasonably expect that applications would use both "math"
and "math3"", I would say yes, we expect it.
>
> 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 ;-).]
Yes, but the change since last time is that now [math] as more users and
with bigger expectations. Another change is that many other commons
components have adopted the policy of changing package name.
>
>>> 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.]
The name change is not for maintaining several versions in parallel. It
is to allow projects to have parts depending on the old (unmaintained)
version and new (maintained) version to compile and let them go back in
sync progressively. It is exactly the same process than the change in
2.2 for the user exceptions: we know there WILL be a transition period
for some projects and we help them during this transition.
Luc
>
>
> 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
