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?
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
