On 2/11/11 3:42 PM, Luc Maisonobe wrote: > Le 11/02/2011 21:34, Phil Steitz a écrit : >> On 2/11/11 3:03 PM, Luc Maisonobe wrote: >>> Le 11/02/2011 20:23, Phil Steitz a écrit : >>>> On 2/11/11 1:53 PM, Luc Maisonobe wrote: >>>>> Le 11/02/2011 19:07, Phil Steitz a écrit : >>>>>> On 2/11/11 12:49 PM, Luc Maisonobe wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I would like to have 2.2 out as soon as possible. I would like to >>>>>>> propose yet another intermediate solution, not a perfect one, but trying >>>>>>> to mitigate everything that has been said here. Remember this is *only* >>>>>>> for 2.2 and it does *not* mean anything about 3.0 or any further >>>>>>> discussions. >>>>>>> >>>>>>> So I propose we release 2.2 with the following changes relative to what >>>>>>> is currently in the repository: >>>>>>> >>>>>>> - change FunctionEvaluationException, DerivativeException and >>>>>>> MatrixVisitorException to unchecked again by making them >>>>>>> extend o.a.c.math.exception.MathUserException >>>>>>> - change ConvergenceException to unchecked by making it extend >>>>>>> o.a.c.math.exception.MathIllegalStateException >>>>>>> - undeprecate all these exceptions >>>>>>> - accept the 17 CLIRR errors remaining after these changes >>>>>>> (13 related to exceptions, 4 related to ODE) >>>>>>> - accept the 30 CLIRR warnings remaining after these changes >>>>>>> (all of them related to exceptions) >>>>>>> - accept the 422 CLIRR infos remaining after these changes >>>>>>> >>>>>>> This is by no means a perfect solution, I really tried to reach a >>>>>>> compromise between several points of view. As each compromise, everyone >>>>>>> would have something to tell against it but please don't start another >>>>>>> lengthy discussion and even less a flame war. There is no hidden >>>>>>> intention behind this and the choices presented would be put only in 2.2 >>>>>>> branch, not in trunk. The only intention is to be able to publish 2.2. >>>>>>> >>>>>>> What do you think ? >>>>>>> >>>>>> Can you create a Clirr report showing the issues above and put it in >>>>>> ~luc so we can all look at it? >>>>> Yes, I have put it there: >>>>> <http://people.apache.org/~luc/clirr-report.html>. >>>>> >>>>>> Also, what would it take to fully eliminate the exceptions-related >>>>>> errors? >>>>> This would mean going back to checked exception as most errors are >>>>> "Removed org.apache.commons.math.MathException from the list of >>>>> superclasses" >>>> So from the user perspective, the compatibility issue is that code >>>> that catches MathException will in some cases propagate runtime >>>> exceptions instead. This sounds ridiculous, but what would be the >>>> implications of just reverting the hierarchy so catching >>>> MathException would work as before, but make MathException itself >>>> unchecked? >>> This could be done. I sincerely simply did not think about it. >>> >>>> Sorry if this seems to be walking into the kind of discussion you >>>> did not want to reopen at this point; but I am just trying to see >>>> what we might be able to do to prevent users having to make code >>>> changes to have their apps that use 2.1 work safely in 2.2. >>> I would say we can't do anything. There are the ODE changes which are >>> flagged as errors by CLIRR even for things which clearly do not belong >>> to the public API like private fields having been replaced. There are >>> also the 2.1 tests that Sebb checked against 2.2 and which fail due to >>> other changes which are not flagged at all by CLIRR because they are >>> semantic changes. >>> >> What if we reverted all of the incompatible changes other than those >> required to fix the ODE bug? That would mean >> >> 1. Revert changes in exception hierarchy >> 2. Revert semantic changes in equals that Sebb flagged >> 3. Anything else? >> >> I honestly don't recall anything else and we could look through the >> tickets to verify no other semantic changes >>>> I will add at this point that if we just s/2.2/3.0 and s/3.0/4.0, I >>>> am fine releasing as is. >>> 2.2 *is* a clumsy version, so promoting it to 3.0 would be really a bad >>> idea as it would imply telling to users « we have done great changes, >>> look at them » to only change everything again. >>> >>> Current 3.0 is more in line with what we want. It will certainly not be >>> perfect either, but much better. >>> >>> So rather than patching this mess once again, we could simply drop 2.2 >>> completely and concentrate our efforts in 3.0 to be able to publish it >>> soon. However, this is not an easy decision. As some of you already >>> know, and as Gary said in his interview recently, we have some great >>> news to publish about some uses of [math]. Dropping 2.2 and waiting >>> months for 3.0 would be really really bad for this. >>> >>> The alternative is therefore: >>> - do we publish a 2.2 that is clumsy but fixes many important bugs >>> and introduces some incompatibilities >>> - do we consider we can publish 3.0 in the next two months so we >>> can afford dropping 2.2 >>> >>> Please, choose one option and stick to it. I am exhausted and depressed, >>> I don't want to argue anymore. >>> >> I am really sorry about this, Luc. I should have complained more >> about the incompatible changes as they were introduced. We now have >> a mess to clean up and I have to take the lion's share of the blame >> for that. So I will volunteer to do the compatability-restoring >> changes if we can agree to them and get a 2.2 RC that has only the >> ODE issue (which looks minor, from a user standpoint). Would you >> be OK with a third alternative, which is release 2.2 with only the >> ODE incompatibility? > Yes. > Great. As long as others are OK with this, I will get to work on this this weekend.
Phil >> Phil >>>> Phil >>>>> Luc >>>>> >>>>>> Phil >>>>>>> Luc >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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
