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] preparing smooth interface upgrade for users
Date Wed, 17 Nov 2010 19:53:09 GMT
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.

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


Mime
View raw message