Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.216.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=YXPJpkr5hnha53MpuwaanUmQ9c+gJeK73oUWa72DQjIJQSUOEXNhbKEoSb13X7iGsE
         uYDfqhCGBgBfQWhHsuNSR29hq3eK0Lk6srkEfpSN6kaqlXF+ipXWRZdeTItrnoS9D5sG
         DdgdiBH6oXxqmDOihJ5beUH4WzXP6WKsmTDRk=
MIME-Version: 1.0
In-Reply-To: <4D55A2DF.4080103@gmail.com>
References: <4D5576B4.8080203@free.fr>
	<4D557ADF.3090407@gmail.com>
	<4D5585C7.5000102@free.fr>
	<4D558CAD.4090006@gmail.com>
	<4D5595F6.4070907@free.fr>
	<4D559D42.7030806@gmail.com>
	<4D559F39.1030405@free.fr>
	<4D55A2DF.4080103@gmail.com>
Date: Fri, 11 Feb 2011 21:12:49 +0000
Message-ID: <AANLkTikpqxpw3L2ViB090O_yBnJZCq-mWFzdy26ZEe5C@mail.gmail.com>
Subject: Re: [math] the 2.2 release saga conclusion ?
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 11 February 2011 20:58, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 2/11/11 3:42 PM, Luc Maisonobe wrote:
>> Le 11/02/2011 21:34, Phil Steitz a =E9crit :
>>> On 2/11/11 3:03 PM, Luc Maisonobe wrote:
>>>> Le 11/02/2011 20:23, Phil Steitz a =E9crit :
>>>>> On 2/11/11 1:53 PM, Luc Maisonobe wrote:
>>>>>> Le 11/02/2011 19:07, Phil Steitz a =E9crit :
>>>>>>> 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:
>>>>>>>>
>>>>>>>> =A0- change FunctionEvaluationException, DerivativeException and
>>>>>>>> =A0 =A0MatrixVisitorException to unchecked again by making them
>>>>>>>> =A0 =A0extend o.a.c.math.exception.MathUserException
>>>>>>>> =A0- change ConvergenceException to unchecked by making it extend
>>>>>>>> =A0 =A0o.a.c.math.exception.MathIllegalStateException
>>>>>>>> =A0- undeprecate all these exceptions
>>>>>>>> =A0- accept the 17 CLIRR errors remaining after these changes
>>>>>>>> =A0 =A0(13 related to exceptions, 4 related to ODE)
>>>>>>>> =A0- accept the 30 CLIRR warnings remaining after these changes
>>>>>>>> =A0 =A0(all of them related to exceptions)
>>>>>>>> =A0- 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, eve=
ryone
>>>>>>>> would have something to tell against it but please don't start ano=
ther
>>>>>>>> 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 i=
n
>>>>>>> ~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. =A0 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? =A0That 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 ba=
d
>>>> idea as it would imply telling to users =AB we have done great changes=
,
>>>> look at them =BB to only change everything again.
>>>>
>>>> Current 3.0 is more in line with what we want. It will certainly not b=
e
>>>> 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:
>>>> =A0- do we publish a 2.2 that is clumsy but fixes many important bugs
>>>> =A0 =A0and introduces some incompatibilities
>>>> =A0- do we consider we can publish 3.0 in the next two months so we
>>>> =A0 =A0can afford dropping 2.2
>>>>
>>>> Please, choose one option and stick to it. I am exhausted and depresse=
d,
>>>> I don't want to argue anymore.
>>>>
>>> I am really sorry about this, Luc. =A0I should have complained more
>>> about the incompatible changes as they were introduced. =A0We now have
>>> a mess to clean up and I have to take the lion's share of the blame
>>> for that. =A0So 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). =A0 Would you
>>> be OK with a third alternative, which is release 2.2 with only the
>>> ODE incompatibility?
>> Yes.
>>
> Great. =A0As 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org