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