commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] preparing smooth interface upgrade for users
Date Fri, 19 Nov 2010 15:39:40 GMT
On 11/19/10 8:52 AM, Luc Maisonobe wrote:
> Le 17/11/2010 21:08, sebb a écrit :
>> On 17 November 2010 19:53, Luc Maisonobe<Luc.Maisonobe@free.fr>  wrote:
>>> Le 17/11/2010 13:48, Phil Steitz a écrit :
>>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote:
>>>>>>>> [...]
>>>>>>>> I think this transition is the smoother path for our users.
Do you
>>>>>>>> think
>>>>>>>> this change is the way to go ?
>>>>>>>
>>>>>>> -0
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>>
>>>>>>> My first impression is that it is a lot of changes for 2.2 without
any
>>>>>>> benefit when users will switch to 3.0; they will still have to
scan
>>>>>>> their
>>>>>>> code for all the exceptions that will have disappeared.
>>>>>>
>>>>>> Won't the deprecations take care of that?
>>>>>
>>>>> I didn't mean that they have to scan "manually", just that they will
>>>>> have to
>>>>> make the same change in 3.0 as they would in 2.2 (not more, not less
>>>>> work).
>>>>> Hence, I see no benefit in breaking the "no compatibility breaking"
>>>>> rule in
>>>>> 2.2.
>>>>
>>>> I think what Luc is suggesting is that by introducing MathUserException
>>>> in 2.2 without a material compatibility break (i.e. nothing that would
>>>> actually break any 2.1 code) we could set users to start doing this work
>>>> incrementally before 3.0 is released.  That seems like a good idea to me
>>>> IIUC what the impacts are.
>>>
>>> You are right, this is exactly what I try to do.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2,
you would
>>>>>>> have to explain to users that it's better that they do it but
that it
>>>>>>> will still work if they don't... And they will probably say:
"If it
>>>>>>> ain't
>>>>>>> broken, I won't fix it." ;-)
>>>>>>
>>>>>> However, deprecation warnings are a strong hint that failure is
>>>>>> imminent, and they may wish to prepare for the change.
>>>>>
>>>>> Yes. We should advertise the list of exceptions that are going to be
>>>>> replaced by "MathUserException" when users switch 3.0, by deprecating
>>>>> them in 2.2.
>>>>> The preparation is to have a perl (or sed or ...) script ready.
>>>>>
>>>> I think we all agree on the deprecations.  I understand your view,
>>>> Gilles, that Luc's suggestion does not reduce work for those upgrading
>>>> to 3.0; but don't you agree it would be helpful for them to be able to
>>>> start - even just with new code they are developing - using the new user
>>>> exception, assuming we can introduce it in 2.2 without breaking anything?
>>>>
>>>> Luc / Sebb - can you see any real backward compat issue?  Would this
>>>> change force a recompile?
>>>
>>> I don't think a recompile should be needed because the new exceptions
>>> going out of the complete integration algorithm are now unchecked, and
>>> in fact since the current exception are checked exception, existing user
>>> code probably already catches them.
>>
>> Should be easy enough to check with some actual source.
>
> I just checked with an old tutorial, compiled with 2.1.
> It runs perfectly and throws exceptions correctly with both 2.1 and the
> current version in 2.X branch with the proposed change, without recompiling.

What happens when you try to recompile it against a new jar built 
from the current sources?

Phil
>
> Luc
>
>>
>>> Luc
>>>
>>>>
>>>> Phil
>>>>>
>>>>> Best,
>>>>> Gilles
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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