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:42:33 GMT
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 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.
>>
> 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, 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.
>>
> 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.

Luc

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