commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [math] preparing smooth interface upgrade for users
Date Wed, 17 Nov 2010 20:08:22 GMT
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.

> 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


Mime
View raw message