OK - would you mind updating MATH-259/MATH-261 accordingly? On 21/05/2009, Phil Steitz <phil.ste...@gmail.com> wrote: > Yes, sorry should have clarified that I was referring to the > s/object/comparable change if freq > > > On 5/21/09, sebb <seb...@gmail.com> wrote: > > 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 > > > > > > --------------------------------------------------------------------- > 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
