Hi all, We have cut a branch for 2.X some times ago and starting work on 3.0. 2.2 is (as far as I am concerned) both a bug fix release and a transition release towards 3.0. The recent thread about repackaging a set of user-related exceptions showed this point of view.
I first intended to wait until MATH-380 was at least partially covered to release 2.2. It appears that the jacobians computation with ODE is yet another bad design from me and add to be completely rewritten. I am working on a new much cleaner design, but it breaks compatibility. Therefore, I postponed MATH-380 to 3.0 and will propose this new design for discussion to the list in the near future with the intent to put it only in 3.0 and not in 2.2. At the same time, working on both 2.X branch and 3.0 trunk becomes a nightmare. I try to keep things in sync as much as possible. I reintroduced some 3.0 exceptions in 2.X because it made sense and allowed smooth transition, clean up javadoc when it announces in the trunk that some class was deprecated in 2.2 when in fact nothing has been put in the branch ... I would very much like to have 2.X released early, preferably in December. I also think 3.0 should be released early (perhaps during spring) as some projects I know of would need it. There are 10 Jira issues open for 2.2. MATH-327 and MATH-383 are about SVD (still not robust enough it seems). I don't know if they can be addressed now or should be postponed. I think we still need to improve our SVD. MATH-408 and MATH-420 have been raised by Phil himself so I probably knows if they should be solved now or not. I think MATH-402 could be fixed, as the spec pointed out by Phil say in note 358 page 532 that complex pow(c,z) could be implemented as exp(c*log(z)) and log(0)=-inf+yi (y being 0 or pi depending on sign of 0) and exp(O+yi)=0 for finite y. The Jira comments and some threads on this list show that much work has already been done on MATH-385, MATH-384, MATH-364, MATH-228 (mostly on the list, not as Jira comments). I'll have a look at MATH-414. I also noticed we now have an increasing number of users and some complex projects among them. So it may be time for us to follow the general trend proposed for commons components and switch our top level package name from org.apache.commons.math to org.apache.commons.math3 for this version. This would help people have both versions in their classpath without names clashes. I'm sure James will be happy with this proposal ;-) So, what do you think ? best regards, Luc --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
