commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] 2.2 compatibility issues
Date Mon, 24 Jan 2011 12:58:45 GMT

----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :

> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz <phil.steitz@gmail.com>
> wrote:
> >> The clirr report run from the current MATH_2_X branch is, as
> expected,
> >> problematic.  To get 2.2. out, we need to agree on what breaks we
> are going
> >> to allow and what we are going to fix.   Here is a first cut and
> proposal
> >> for some immediate fixes that I would appreciate feedback on.
> >>
> >> 0)  The improvements to the distributions classes to add
> characteristic
> >> support and positive mass domains have added some new methods to
> interfaces
> >> and new abstract methods to abstract classes.  I apologize for not
> spotting
> >> this in initial patch reviews or being clear in discussion of the
> >> features.   I think we can keep the functionality without
> introducing the
> >> compatibility breaks by removing the added methods from interfaces
> /
> >> abstract classes.  The only painful part is the nice solution for
> caching
> >> numerical characteristics that will have to be repeated in the
> >> implementation classes that need it.  I would like to proceed with
> these
> >> changes in the 2.2 branch if others are OK with it.
> >
> > Fixed
> >>
> >> 1) Removed superclasses in the exception hierarchy.  I am OK
> leaving these
> >> as is.
> >
> > I am now starting to wonder if we should fix this.  Problem is user
> > code that may be catching the superclass exceptions (which is why
> > clirr is complaining).
> >
> 
> Sorry to flip/flop on this, but I now think we really need to fix
> this
> (i,e., revert the incompatible changes). I have started doing the
> work, most of which is replacing the new, unchecked MathUserException
> with the deprecated checked FunctionEvaluationException.   I don't
> think we *need* to force users to do refactor or surprise them with
> unchecked exceptions in the upgrade to 2.2 and I am willing to do the
> work to fix this.   If I hear no objections, I will commit the
> changes
> when I have finished (next day or two).  We can add some info to the
> release notes warning users of upcoming incompatible changes in 3.0.

I do object.
As the new exception are unchecked, users were not forced to migrate
immediately, but those users who where ready to migrate (for example
due to their own publication schedule) could do so.

Reverting this change force them to go back first, then to wait for 3.0
and do the change at that time. This is exactly what happens to me for
Orekit.

The change was designed as a smooth transition and allowing users
to change at their own pace. So I would prefer these change to be
available in 2.2.

Luc

> 
> Phil
> 
> >>
> >> I don't know what, if anything, to do about the following:
> >>
> >> 2) Changed return type of interpolate in BicubicSpline.
> >
> > Fixed
> >>
> >> 3) Incompatible changes in the ode package.
> >
> > I agree that unfortunately this is hopeless.
> >
> >>
> >> 4) Incompatible changes in the optimization package.
> >
> > Fixing...
> >
> > Phil
> >
> 
> ---------------------------------------------------------------------
> 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