commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] top-level package name
Date Thu, 21 May 2009 11:57:38 GMT
OK - would you mind updating MATH-259/MATH-261 accordingly?

On 21/05/2009, Phil Steitz <phil.steitz@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 <sebbaz@gmail.com> wrote:
>  > On 21/05/2009, Phil Steitz <phil.steitz@gmail.com> wrote:
>  >> Luc Maisonobe wrote:
>  >>
>  >> > sebb a écrit :
>  >> >
>  >> >
>  >> > > On 19/05/2009, James Carman <james@carmanconsulting.com> wrote:
>  >> > >
>  >> > >
>  >> > > > On Tue, May 19, 2009 at 6:53 AM,  <luc.maisonobe@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-unsubscribe@commons.apache.org
>  >> > > >  For additional commands, e-mail: dev-help@commons.apache.org
>  >> > > >
>  >> > > >
>  >> > > >
>  >> > > >
>  >> > >
>  >> ---------------------------------------------------------------------
>  >> > > To unsubscribe, e-mail:
>  >> dev-unsubscribe@commons.apache.org
>  >> > > For additional commands, e-mail: dev-help@commons.apache.org
>  >> > >
>  >> > >
>  >> > >
>  >> > >
>  >> >
>  >> >
>  >> >
>  >> ---------------------------------------------------------------------
>  >> > To unsubscribe, e-mail:
>  >> dev-unsubscribe@commons.apache.org
>  >> > For additional commands, e-mail: dev-help@commons.apache.org
>  >> >
>  >> >
>  >> >
>  >>
>  >>
>  >> ---------------------------------------------------------------------
>  >>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  >>  For additional commands, e-mail: dev-help@commons.apache.org
>  >>
>  >>
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message