commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 2.2 compatibility issues
Date Mon, 24 Jan 2011 14:22:38 GMT
On Mon, Jan 24, 2011 at 7:58 AM,  <luc.maisonobe@free.fr> wrote:
>
> ----- "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.
>
The problem is the users who are catching FunctionEvaluationException,
the checked exception that occurs in *lots* of places in the 2.1 code.
 I don't see how 2.1 users are going to be able to avoid lots of
changes to get 2.2 to work.  Could be I am missing something.  Is it
really true somehow that 2.1 users will not have to make changes?
Sorry if I am being dense here.

> Reverting this change force them to go back first,

Only if they have started using the 2_X branch or trunk before it was
split.  Our compatibility obligation is against *released* code.

 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.
>
If I can understand how 2.1 code that catches and handles
FunctionEvaluationException  will still work, then I am OK with this;
otherwise I really think we need to revert.  I should have yelled more
loudly about the incompatible changes as they were introduced in trunk
prior to the 3.0 split.  Given that we have split 3.0, there is no
reason for us to break Commons guidelines for 2.2 unless there is no
other way to fix bugs (as I assume is the case in some of the ODE
changes).

Phil


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

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


Mime
View raw message