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 (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.212.43 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=EXC8hXDw64cyDsNDQ04zcijGuPJVNJRd+8Vk9X5g3a/Tson5m+4q3MmXd/Rn31loSm
         t+9UEyibk9KNwg0tmawxnjfpF3JDKkNrNSrEL6t9Cd84hYxW6j4PckptCRb3EyKHAyxE
         ahVqkmCLQXXWV8vbSKZHlOue+Hd0pUXpfzWkM=
Message-ID: <4D559D42.7030806@gmail.com>
Date: Fri, 11 Feb 2011 15:34:10 -0500
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] the 2.2 release saga conclusion ?
References: <4D5576B4.8080203@free.fr> <4D557ADF.3090407@gmail.com>
 <4D5585C7.5000102@free.fr> <4D558CAD.4090006@gmail.com>
 <4D5595F6.4070907@free.fr>
In-Reply-To: <4D5595F6.4070907@free.fr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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?

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