commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] the 2.2 release saga conclusion ?
Date Fri, 11 Feb 2011 20:03:02 GMT
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 and
>>>>    MatrixVisitorException to unchecked again by making them
>>>>    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 changes
>>>>    (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, everyone
>>>> 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:
>> <http://people.apache.org/~luc/clirr-report.html>.
>>
>>> Also, what would it take to fully eliminate the exceptions-related
>>> errors?
>> This would mean going back to checked exception as most errors are
>> "Removed org.apache.commons.math.MathException from the list of
>> 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.

> 
> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I
> 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 be
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.

Luc

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


Mime
View raw message