You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2011/02/11 18:49:40 UTC
[math] the 2.2 release saga conclusion ?
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 ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Mikkel Meyer Andersen <mi...@mikl.dk>.
Hi Luc,
+1
Thanks for the constructive post. I agree with the compromise although I
don't have the entire outlook of pros and cons.
Cheers, Mikkel.
Den 11/02/2011 18.50 skrev "Luc Maisonobe" <Lu...@free.fr>:
> 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 ?
>
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [math] the 2.2 release saga conclusion ?
Posted by Paul Benedict <pb...@apache.org>.
I believe re-organizing the exception hierarchy is a great feature for a
major release. For minor releases, avoid refactoring that would break
current code.
Paul
On Fri, Feb 11, 2011 at 1:23 PM, Phil Steitz <ph...@gmail.com> wrote:
> 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?
>
> 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 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.
>
> Phil
>
Re: [math] the 2.2 release saga conclusion ?
Posted by Michael Giannakopoulos <mi...@gmail.com>.
Update: changes.xml found also... :D
Clirr report and jira tickets issue remains...
Re: [math] the 2.2 release saga conclusion ?
Posted by Michael Giannakopoulos <mi...@gmail.com>.
Update: Userguide found...
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
On 2/13/11 11:11 AM, Michael Giannakopoulos wrote:
> Hi Phil,
> I'm sending this mail in order to be sure that i have understood correct
> some of the tasks and to ask for others...
>
>> * Review javadoc for typos / errors
> The revision is done from the comments in the source code in the repository
> for math 2.2 branch... (comments that generate javadoc)
>
Correct. For this and most of the other tasks, the best thing to do
is to checkout the 2_X branch and run "mvn site" to generate the
full site locally. The locally generated site will be in
target/site (where "target" is relative from where the root of the
checkout is on your local machine). The API docs will be in
target/site/apidocs. I usually review the generated docs and look
back at the source to fix / improve anything that needs work.
Do not hesitate to ask if you are having problems getting maven set
up or running it.
>> * Review userguide to make sure it is still accurate and / or
>> contribute some new / better examples
> I have found the userguide in the following link "
> http://commons.apache.org/math/". However i cannot find the latest edition
> of userguide and i don't know how to change its contents in case i find an
> error...
>
When you generate the site locally as above, the userguide gets
generated and is accessible via the main page using the same link
that works in the live site. If you want to open it directly, use
target/site/userguide/index.html
>> * Review clirr report and make sure there are no @since tags missing
The clirr report (under Project Reports) provides a summary of the
API changes since the last release. You can see the report via the
link there, or directly here:
target/site/clirr-report.html
Any public or protected methods, classes, fields or interfaces that
have been added in 2.2 should have @since javadoc tags. The clirr
report is a good way to check to make sure we haven't missed any.
> I have no idea what this means and where i can find it...
>
>> * Review changes.xml for typos / misleading or incomplete
>> descriptions. This is used to generate the release notes, so some
>> cleanup may be required in this file. Also make sure there are no
>> changes described that were either rolled back from or not applied
>> to the 2_X branch (I think I have already verified this; but more
>> eyeballs are good)
> I cannot find where changes.xml file is located. Can you please help me?
I think you said below that you found this, but it is in
src/site/xdoc/changes
The generated report is in
target/site/changes-report.html
> Sorry for my ignorance and for asking these trivial questions to you, but i
> really want to help and to learn! Thanks for your time!
No problem at all. Thanks in advance for your help!
Phil
> Friendly,
> Michael Giannakopoulos
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Michael Giannakopoulos <mi...@gmail.com>.
Hi Phil,
I'm sending this mail in order to be sure that i have understood correct
some of the tasks and to ask for others...
> * Review javadoc for typos / errors
The revision is done from the comments in the source code in the repository
for math 2.2 branch... (comments that generate javadoc)
> * Review userguide to make sure it is still accurate and / or
> contribute some new / better examples
I have found the userguide in the following link "
http://commons.apache.org/math/". However i cannot find the latest edition
of userguide and i don't know how to change its contents in case i find an
error...
> * Review clirr report and make sure there are no @since tags missing
I have no idea what this means and where i can find it...
> * Review changes.xml for typos / misleading or incomplete
> descriptions. This is used to generate the release notes, so some
> cleanup may be required in this file. Also make sure there are no
> changes described that were either rolled back from or not applied
> to the 2_X branch (I think I have already verified this; but more
> eyeballs are good)
I cannot find where changes.xml file is located. Can you please help me?
Sorry for my ignorance and for asking these trivial questions to you, but i
really want to help and to learn! Thanks for your time!
Friendly,
Michael Giannakopoulos
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
On 2/12/11 2:24 AM, Michael Giannakopoulos wrote:
> Hi guys,
> As far as exceptions is concerned it is a major change in the code and
> leaving it out from the 2.2 release is a good idea. About the exceptions i
> would like to point that in some cases new exceptions are needed so as to be
> more clear to developers which one of them to use...
>
>> 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.
> Luc what do you mean by this? There are two versions of code out there?
> Sorry for these questions but this is new to me...
Yes, there are two different branches
http://svn.apache.org/repos/asf/commons/proper/math/trunk
http://svn.apache.org/repos/asf/commons/proper/math/branches/MATH_2_X
The top one is where 3.0 development is happening. The bottom one
holds the source for the 2.2 release.
> I'm willing to help so as to publish 2.2. Thank you all for your time!
>
Thanks!
Any of the following would help move us along
* Review javadoc for typos / errors
* Review userguide to make sure it is still accurate and / or
contribute some new / better examples
* Review JIRA tickets resolved since 2.1 (with fix version 2.2) and
make sure there are no other semantic changes
* Review clirr report and make sure there are no @since tags missing
(could be Sebb has done this already)
* Review changes.xml for typos / misleading or incomplete
descriptions. This is used to generate the release notes, so some
cleanup may be required in this file. Also make sure there are no
changes described that were either rolled back from or not applied
to the 2_X branch (I think I have already verified this; but more
eyeballs are good)
Phil
> Best regards,
> Giannakopoulos Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Michael Giannakopoulos <mi...@gmail.com>.
Hi guys,
As far as exceptions is concerned it is a major change in the code and
leaving it out from the 2.2 release is a good idea. About the exceptions i
would like to point that in some cases new exceptions are needed so as to be
more clear to developers which one of them to use...
>
>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.
Luc what do you mean by this? There are two versions of code out there?
Sorry for these questions but this is new to me...
I'm willing to help so as to publish 2.2. Thank you all for your time!
Best regards,
Giannakopoulos Michael
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
On 2/11/11 4:12 PM, sebb wrote:
> On 11 February 2011 20:58, Phil Steitz <ph...@gmail.com> wrote:
>> 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.
> +1.
>
> I can do MathUtils if that helps.
>
> May also have time for some others.
Thanks!
Phil
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by sebb <se...@gmail.com>.
On 11 February 2011 20:58, Phil Steitz <ph...@gmail.com> wrote:
> 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.
+1.
I can do MathUtils if that helps.
May also have time for some others.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
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-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Luc Maisonobe <Lu...@free.fr>.
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.
Luc
>
> Phil
>>
>>> Phil
>>>> Luc
>>>>
>>>>> Phil
>>>>>> Luc
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
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?
Phil
>
>> Phil
>>> Luc
>>>
>>>> Phil
>>>>> Luc
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Luc Maisonobe <Lu...@free.fr>.
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.
>
> 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.
Luc
>
> Phil
>> Luc
>>
>>> Phil
>>>> Luc
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
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?
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 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.
Phil
> Luc
>
>> Phil
>>> Luc
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by sebb <se...@gmail.com>.
On 11 February 2011 18:53, Luc Maisonobe <Lu...@free.fr> 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"
BTW, I have run the 2.1 test cases against the current 2.2 code.
There are a lot of errors and failures. Many of them relate to the
changes in exception hierarchy - e.g. expecting MathException, actual
NullArgumentException.
Some are obviously OK, e.g. the following fails:
assertFalse(ex.getMessage().equals(ex.getMessage(Locale.FRENCH)));
[Not sure that was a safe test anyway - suppose the default Locale was FRENCH?]
However, there are also errors in MathUtils (e.g. changes in equals methods).
I'm not sure it's a good idea to change the behaviour in a point
release, unless the current behaviour is obviously incorrect.
The behaviour wrt NaNs has been changed, and it no longer agrees with
the Javadoc for 2.1.
I think in this case it would be safer to introduce the new
equalsIncludingNaN() methods, but keep the old equals() method
behaviour.
Otherwise user code may break - as does the test code.
Sorry, I realise that I should have brought this up a long while ago,
but I was not really following the changes initially.
> Luc
>
>>
>> Phil
>>> Luc
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Luc Maisonobe <Lu...@free.fr>.
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"
Luc
>
> Phil
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] the 2.2 release saga conclusion ?
Posted by Phil Steitz <ph...@gmail.com>.
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?
Also, what would it take to fully eliminate the exceptions-related
errors?
Phil
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org