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