On 21/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > 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. >
By "this one" do you mean the change to the Frequency parameter type? If so, does your own code make use of the class in ways which are not currently represented in the unit-test code? Might be worth tweaking the test code if so. > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
