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
