> > 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
changes?]
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?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
