On Nov 19, 2010, at 9:50 AM, Luc Maisonobe <luc.maison...@free.fr> wrote:
> Le 19/11/2010 16:39, Phil Steitz a écrit :
>> 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.maison...@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?
>
> The compiler displays a warning, as expected:
> Note: ODEExample.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> Luc
>
Great. Then +1 for the change.
>>
>> Phil
>>>
>>> Luc
>>>
>>>>
>>>>> Luc
>>>>>
>>>>>>
>>>>>> Phil
>>>>>>>
>>>>>>> Best,
>>>>>>> Gilles
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
