commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] top-level package name
Date Tue, 19 May 2009 18:54:17 GMT
> > I don't understand why version 2.0 should be assimilated to a new project.
> >  Is there someone who is going to work on the v1.2 code base? If not, what is
> >  the gain?
> >  Anyone who has an application that runs under v1.2 can still use the
> >  old JAR, which will be forever compatible.
> Yes, that's fine for many applications.
> Howver, the application could include other software that required a
> later version of Math; the only sure way to avoid clashes is to use
> different class names.

If eternal backward compatibility is paramount, then for every major
version change you'd require a new name ("math3" for v3.0, and so on).
[Indeed, what is the difference between major a minor version numbers
Then, that will create a mess of seemingly different projects, all but the
last one being dead!

Moreover, to refer to your example, how can a software depend from a *later*
version of Math (since it does not exist yet)?
To be clearer, suppose that, as of now,
 * A (v1.0) depends on
   - B (v1.0)
   - Math (v1.2)

 * B (v1.0) depends on
   - Math (v1.2)

Everything works fine, and will continue to work as long as A's code and its
dependencies artefacts are not touched.

Then, "later",
 * B (v3.0) depends on
   - Math (v2.0)

Things will possibly start to break *only* if A's maintainer wants to
upgrade to B (v3.0), but if he does that, he should be prepared to do
some work on his code. Why not, since he replaced a component with a new one
with a major version number bump?
Why should the Math project be responsible for this kind of "transitive"
compatibility problems? Do I miss something?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message