Luc Maisonobe wrote:
sebb a écrit :
On 19/05/2009, James Carman <ja...@carmanconsulting.com> wrote:
On Tue, May 19, 2009 at 6:53 AM, <luc.maison...@free.fr> wrote:
> Hello,
>
> Considering the ongoing discussion in another thread, the current changes
that have been done on [math] for the last months belong to the major changes with
large incompatibilities with previous versions.
Are you sure that there are large incompatibilities?
Yes. There have been several packages reorganizations in analysis, ode,
linear and optimization by adding subpackages and moving classes. There
have been some renamed classes (mainly in ode). There have been very
large changes in linear and optimization (almost all classes have
changed I think) and new methods have been added to interfaces. Every
deprecated API from 1.x have been removed.
When possible, the old API have been simply deprecated so they can be
removed later, but it was not always possible (I don't remember each
case, sorry).
As suggested by Hen, I ran a clirr report with respect to 1.2, it
triggered 183 errors (including the deprecated methods that have been
removed).
I thought you were trying to preserve API compatibility?
Yes, for minor versions. However, since there were some needed changes
in ode and linear, we decided to take the opportunity to concentrate all
changes in one move once it had been decided to start.
We have already decided that the version number will be 2.0 to acknowledge
that. I know of at least one big international research project that uses
commons-math 1.2 and will switch to 2.0 when it will be published. They have
already faced compatibility problems recently (two days ago).
>
> Should we change the top level package name from org.apache.commons.math to
org.apache.commons.math2 ?
I'd say yes.
In that case, it should be OK to break compatibility in the Frequency
class by requiring that parameters be Comparable rather than Object -
see MATH-259 & MATH-261 - which will improve compile-time safety.
As far as I am concerned, I'll say yes. In fact, I was even wondering
why stopping the changes here when we have the opportunity.
I am OK with this one after testing my own code (with user hat on),
which does not break. I was against it at first since I want us to
stick with the principle of minimizing incompatible change.
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
---------------------------------------------------------------------
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
