On Mon, Jan 24, 2011 at 11:01 AM, <luc.maison...@free.fr> wrote: > > ----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : > >> On Mon, Jan 24, 2011 at 7:58 AM, <luc.maison...@free.fr> wrote: >> > >> > ----- "Phil Steitz" <phil.ste...@gmail.com> a écrit : >> > >> >> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz >> <phil.ste...@gmail.com> >> >> wrote: >> >> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz >> <phil.ste...@gmail.com> >> >> wrote: >> >> >> The clirr report run from the current MATH_2_X branch is, as >> >> expected, >> >> >> problematic. To get 2.2. out, we need to agree on what breaks >> we >> >> are going >> >> >> to allow and what we are going to fix. Here is a first cut >> and >> >> proposal >> >> >> for some immediate fixes that I would appreciate feedback on. >> >> >> >> >> >> 0) The improvements to the distributions classes to add >> >> characteristic >> >> >> support and positive mass domains have added some new methods >> to >> >> interfaces >> >> >> and new abstract methods to abstract classes. I apologize for >> not >> >> spotting >> >> >> this in initial patch reviews or being clear in discussion of >> the >> >> >> features. I think we can keep the functionality without >> >> introducing the >> >> >> compatibility breaks by removing the added methods from >> interfaces >> >> / >> >> >> abstract classes. The only painful part is the nice solution >> for >> >> caching >> >> >> numerical characteristics that will have to be repeated in the >> >> >> implementation classes that need it. I would like to proceed >> with >> >> these >> >> >> changes in the 2.2 branch if others are OK with it. >> >> > >> >> > Fixed >> >> >> >> >> >> 1) Removed superclasses in the exception hierarchy. I am OK >> >> leaving these >> >> >> as is. >> >> > >> >> > I am now starting to wonder if we should fix this. Problem is >> user >> >> > code that may be catching the superclass exceptions (which is >> why >> >> > clirr is complaining). >> >> > >> >> >> >> Sorry to flip/flop on this, but I now think we really need to fix >> >> this >> >> (i,e., revert the incompatible changes). I have started doing the >> >> work, most of which is replacing the new, unchecked >> MathUserException >> >> with the deprecated checked FunctionEvaluationException. I don't >> >> think we *need* to force users to do refactor or surprise them >> with >> >> unchecked exceptions in the upgrade to 2.2 and I am willing to do >> the >> >> work to fix this. If I hear no objections, I will commit the >> >> changes >> >> when I have finished (next day or two). We can add some info to >> the >> >> release notes warning users of upcoming incompatible changes in >> 3.0. >> > >> > I do object. >> > As the new exception are unchecked, users were not forced to >> migrate >> > immediately, but those users who where ready to migrate (for >> example >> > due to their own publication schedule) could do so. >> > >> The problem is the users who are catching >> FunctionEvaluationException, >> the checked exception that occurs in *lots* of places in the 2.1 >> code. > > These users still catch FunctionEvaluationException which still exists, > still is is the same package, but is unchecked. So they could avoid catching > it but if they do, it will work. > >> I don't see how 2.1 users are going to be able to avoid lots of >> changes to get 2.2 to work. Could be I am missing something. Is it >> really true somehow that 2.1 users will not have to make changes? > > For this specific point, I don't think they need to change anything. This > is what I tested some weeks ago.
I am sorry, Luc. This is what I was missing / forgot that you had tested. I am OK with this. > There are other points where change would be needed, as some incompatible > changes were introduced to solve bugs. > Per my previous note, I think the compatibility-breaking changes in optimization can be reverted without losing the associated bug fixes. If there is no way to do it in ode, then so be it. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
