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:01:34 GMT
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. 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


Mime
View raw message