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