commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] the 2.2 release saga conclusion ?
Date Fri, 11 Feb 2011 22:19:09 GMT
On 2/11/11 4:12 PM, sebb wrote:
> On 11 February 2011 20:58, Phil Steitz <> wrote:
>> On 2/11/11 3:42 PM, Luc Maisonobe wrote:
>>> Le 11/02/2011 21:34, Phil Steitz a écrit :
>>>> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
>>>>> Le 11/02/2011 20:23, Phil Steitz a écrit :
>>>>>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>>>>>>> Le 11/02/2011 19:07, Phil Steitz a écrit :
>>>>>>>> On 2/11/11 12:49 PM, Luc Maisonobe wrote:
>>>>>>>>> Hi all,
>>>>>>>>> I would like to have 2.2 out as soon as possible. I would
like to
>>>>>>>>> propose yet another intermediate solution, not a perfect
one, but trying
>>>>>>>>> to mitigate everything that has been said here. Remember
this is *only*
>>>>>>>>> for 2.2 and it does *not* mean anything about 3.0 or
any further
>>>>>>>>> discussions.
>>>>>>>>> So I propose we release 2.2 with the following changes
relative to what
>>>>>>>>> is currently in the repository:
>>>>>>>>>  - change FunctionEvaluationException, DerivativeException
>>>>>>>>>    MatrixVisitorException to unchecked again by making
>>>>>>>>>    extend o.a.c.math.exception.MathUserException
>>>>>>>>>  - change ConvergenceException to unchecked by making
it extend
>>>>>>>>>    o.a.c.math.exception.MathIllegalStateException
>>>>>>>>>  - undeprecate all these exceptions
>>>>>>>>>  - accept the 17 CLIRR errors remaining after these changes
>>>>>>>>>    (13 related to exceptions, 4 related to ODE)
>>>>>>>>>  - accept the 30 CLIRR warnings remaining after these
>>>>>>>>>    (all of them related to exceptions)
>>>>>>>>>  - accept the 422 CLIRR infos remaining after these changes
>>>>>>>>> This is by no means a perfect solution, I really tried
to reach a
>>>>>>>>> compromise between several points of view. As each compromise,
>>>>>>>>> would have something to tell against it but please don't
start another
>>>>>>>>> lengthy discussion and even less a flame war. There is
no hidden
>>>>>>>>> intention behind this and the choices presented would
be put only in 2.2
>>>>>>>>> branch, not in trunk. The only intention is to be able
to publish 2.2.
>>>>>>>>> What do you think ?
>>>>>>>> Can you create a Clirr report showing the issues above and
put it in
>>>>>>>> ~luc so we can all look at it?
>>>>>>> Yes, I have put it there:
>>>>>>> <>.
>>>>>>>> Also, what would it take to fully eliminate the exceptions-related
>>>>>>>> errors?
>>>>>>> This would mean going back to checked exception as most errors
>>>>>>> "Removed org.apache.commons.math.MathException from the list
>>>>>>> superclasses"
>>>>>> So from the user perspective, the compatibility issue is that code
>>>>>> that catches MathException will in some cases propagate runtime
>>>>>> exceptions instead.   This sounds ridiculous, but what would be the
>>>>>> implications of just reverting the hierarchy so catching
>>>>>> MathException would work as before, but make MathException itself
>>>>>> unchecked?
>>>>> This could be done. I sincerely simply did not think about it.
>>>>>> Sorry if this seems to be walking into the kind of discussion you
>>>>>> did not want to reopen at this point; but I am just trying to see
>>>>>> what we might be able to do to prevent users having to make code
>>>>>> changes to have their apps that use 2.1 work safely in 2.2.
>>>>> I would say we can't do anything. There are the ODE changes which are
>>>>> flagged as errors by CLIRR even for things which clearly do not belong
>>>>> to the public API like private fields having been replaced. There are
>>>>> also the 2.1 tests that Sebb checked against 2.2 and which fail due to
>>>>> other changes which are not flagged at all by CLIRR because they are
>>>>> semantic changes.
>>>> What if we reverted all of the incompatible changes other than those
>>>> required to fix the ODE bug?  That would mean
>>>> 1. Revert changes in exception hierarchy
>>>> 2. Revert semantic changes in equals that Sebb flagged
>>>> 3. Anything else?
>>>> I honestly don't recall anything else and we could look through the
>>>> tickets to verify no other semantic changes
>>>>>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0,
>>>>>> am fine releasing as is.
>>>>> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad
>>>>> idea as it would imply telling to users « we have done great changes,
>>>>> look at them » to only change everything again.
>>>>> Current 3.0 is more in line with what we want. It will certainly not
>>>>> perfect either, but much better.
>>>>> So rather than patching this mess once again, we could simply drop 2.2
>>>>> completely and concentrate our efforts in 3.0 to be able to publish it
>>>>> soon. However, this is not an easy decision. As some of you already
>>>>> know, and as Gary said in his interview recently, we have some great
>>>>> news to publish about some uses of [math]. Dropping 2.2 and waiting
>>>>> months for 3.0 would be really really bad for this.
>>>>> The alternative is therefore:
>>>>>  - do we publish a 2.2 that is clumsy but fixes many important bugs
>>>>>    and introduces some incompatibilities
>>>>>  - do we consider we can publish 3.0 in the next two months so we
>>>>>    can afford dropping 2.2
>>>>> Please, choose one option and stick to it. I am exhausted and depressed,
>>>>> I don't want to argue anymore.
>>>> I am really sorry about this, Luc.  I should have complained more
>>>> about the incompatible changes as they were introduced.  We now have
>>>> a mess to clean up and I have to take the lion's share of the blame
>>>> for that.  So I will volunteer to do the compatability-restoring
>>>> changes if we can agree to them and get a 2.2 RC that has only the
>>>> ODE issue (which looks minor, from a user standpoint).   Would you
>>>> be OK with a third alternative, which is release 2.2 with only the
>>>> ODE incompatibility?
>>> Yes.
>> Great.  As long as others are OK with this, I will get to work on
>> this this weekend.
> +1.
> I can do MathUtils if that helps.
> May also have time for some others.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message