commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: AW: [math] roadmap for 2.X and 3.0 ?
Date Wed, 24 Nov 2010 17:57:23 GMT
Le 24/11/2010 18:44, sebb a écrit :
> On 24 November 2010 17:01, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>> Le 24/11/2010 17:19, Dietmar Wolz a écrit :
>>>
>>>
>>>> that depends on math 2.1.  Orekit itself (or whatever other immediate
>>>> dependency) may not have cut a release changing its internal use to 3.0.
 At
>>>
>>> Is this realistic? I would expect quite early an Orekit version supporting CM
>>> 3.0.
>>
>> For Orekit, you are right, we will be 3.0 ready very early but it is a
>> somewhat ideal situation: the same people are involved in both tools.
>> Also in the example situation I presented, the problem is in fact the
>> other way round: Orekit will switch to 3.0 much earlier than the top
>> level project. This does not change the problem, though: in both cases
>> we have two libraries that need two different versions, their relative
>> ordering is irrelevant.
>>
>>> May be not a release but the actual Orekit trunk. So for your own release you
>>> would have to wait for the next Orekit release which is CM 3.0 compatible.
>>> But in the meantime you can still test your CM 3.0 compatible stuff - by using
>>> a not yet officially released Orekit version.
>>> Are there projects where such a procedure is not acceptable?
>>
>> There are operational projects that are not allowed to rely on
>> unpublished versions. The intermediate libraries may also be
>> closed-source and people may simply not want to buy new versions too
>> often. So they would have to wait for an official release of
>> commons-math, then an official release of ALL the libraries that depend
>> on commons-math, then they could start upgrading themselves. As some
>> libraries may well be stable enough to not require publishing a new
>> version, that would condemn their users to stick to commons-math 2.x for
>> a long time.
>>
>> This is one classical situation for jar hell: project A uses components
>> B1 and B2 and both components use a low level C component. A bug is
>> discovered in C and it is a major one for B1. Then a new version of C is
>> published, followed by a new version of B1 that depends on it. However
>> B2 is not affected by this bug and is a stable component: it does not
>> update its use of C and still rely on the old version with the bug.
>> Project A is in jar hell.
> 
> It's only in jar hell if C2 is not binary compatible with C1 (and then
> only if B2 uses the part of C1 that changed in C2)

Yes, sorry, the example was not complete.

thanks for the clarification
Luc

> 
> Otherwise, surely just replace C with Cv2 and both B1 and B2 are happy?
> 
> If C1 and C2 have the same Maven gid:aid combination, only C2 willl be
> put on the classpath.
> 
>> The situation is worse if B2 is not an
>> open-source project, as project A really cannot make the change by itself.
>>
>> Luc
>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message