[math] Ready for 1.0 RC?

[Phil Steitz <ph...@steitz.com>]

I have finished with the coding / docs tasks that I thought needed to get 
done before 1.0. There are no open BZ tickets and the reports (checkstyle, 
javadoc, clover) are looking OK.  I regenerated and published the site 
based on the current build this AM. Other than the changes required to get 
the right names associated and cut the release, is there anything else 
that needs to be fixed / completed prior to 1.0?

I am tempted to make one more API change; but am ambivalent about it:
Currently the API for (non-paired) TTests uses a boolean flag to indicate 
whether or not the test is being performed under the hypothesis of equal 
subpopulation variances (homoscedastic test). Recently, [lang] added a 
development guideline to avoid boolean flags in APIs.  I thought about 
splitting the homoscedastic tests out (as I did the paired tests); but 
decided not to (partly because of the long name and proliferation of 
methods).  Does anyone feel strongly that this should be changed?

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Ready for 1.0 RC?

[md...@latte.harvard.edu]

Quoting Phil Steitz <ph...@steitz.com>:

> I have finished with the coding / docs tasks that I thought needed to get 
> done before 1.0. There are no open BZ tickets and the reports (checkstyle, 
> javadoc, clover) are looking OK.  I regenerated and published the site 
> based on the current build this AM. Other than the changes required to get 
> the right names associated and cut the release, is there anything else 
> that needs to be fixed / completed prior to 1.0?
> 

I'm out of town this week, but feel free to release without me if you feel up 
to it.

> I am tempted to make one more API change; but am ambivalent about it:
> Currently the API for (non-paired) TTests uses a boolean flag to indicate 
> whether or not the test is being performed under the hypothesis of equal 
> subpopulation variances (homoscedastic test). Recently, [lang] added a 
> development guideline to avoid boolean flags in APIs.  I thought about 
> splitting the homoscedastic tests out (as I did the paired tests); but 
> decided not to (partly because of the long name and proliferation of 
> methods).  Does anyone feel strongly that this should be changed?
> 

Why avoid returning boolean flags? They are as much part of the Java API as 
anything else? I whish I had my usuall mail application, I'd search and review 
the discussion. Can you post briefly why [lang] decided this? I'm not 
convinced yet that its a necessity, the API can be changed in future versions.

-Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [math] Ready for 1.0 RC?

[Al Chou <ho...@yahoo.com>]

--- Phil Steitz <ph...@steitz.com> wrote:
> I have finished with the coding / docs tasks that I thought needed to get 
> done before 1.0. There are no open BZ tickets and the reports (checkstyle, 
> javadoc, clover) are looking OK.  I regenerated and published the site 
> based on the current build this AM. Other than the changes required to get 
> the right names associated and cut the release, is there anything else 
> that needs to be fixed / completed prior to 1.0?
> 
> I am tempted to make one more API change; but am ambivalent about it:
> Currently the API for (non-paired) TTests uses a boolean flag to indicate 
> whether or not the test is being performed under the hypothesis of equal 
> subpopulation variances (homoscedastic test). Recently, [lang] added a 
> development guideline to avoid boolean flags in APIs.  I thought about 
> splitting the homoscedastic tests out (as I did the paired tests); but 
> decided not to (partly because of the long name and proliferation of 
> methods).  Does anyone feel strongly that this should be changed?

If the change is pretty easy to make, I'd say write the tests and make the
change now, rather than after the release.  We know 1.0 isn't perfect, but I
think it's worth making this change, especially as it will make non-paired
TTest usage consistent with paired TTests.

Al

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org