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.
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
