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 <luc.maison...@free.fr> 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
>> <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
