commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] roadmap for 2.X and 3.0 ?
Date Wed, 24 Nov 2010 15:49:55 GMT
On Wed, Nov 24, 2010 at 10:34 AM, Gilles Sadowski <> wrote:

> Hello.
> > 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?),
> Wouldn't it mean that at least one of the two libraries is not an active
> project? Otherwise I'd think they would benefit from upgrading.

Not necessarily.  The Orekit example that Luc gave is a good one.   A
project could use [math] directly and be very actively maintained and
needing the 3.0 features / fixes, but depend on an earlier version of Orekit
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
that point, the project using both [math] directly and Orekit needs to have
both versions available.  Since dependency on the 2.1 code is encapsulated
in Orekit, there is no need for the [math] versions to be compatible for the
app to work.

> Another aspect is that, by making it possible, we would encourage "lazy"
> users to not upgrade, and would thus loose them as "testers" of the new
> releases.
> It's nice to help users[1] but we should not forget that we can be
> confident
> in the code only if it is largely used. Bugs in the "linear" package went
> unnoticed until a real-world code stressed it.
> So, I'm not sure that, at this point, we can afford "lazy" users ;-) [I'm
> playing the devil's advocate here.]

As I said, the use case driving the need for the package name change is
really beyond users' control, so I am +1 on the package name change for 3.0


> > [...]
> Gilles
> [1] I would be the first to have a little less work as a result of the name
>    change.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message