On Wed, Nov 24, 2010 at 4:38 AM, Luc Maisonobe <luc.maison...@free.fr>wrote:
> 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. > +1 > > 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 ... > +1 on trying to keep javadoc consistent - when we add "deprecated in 2.2" in trunk we need to actually do the deprecation in the 2.x branch (preferably in the same commit). We don't have to be perfect in comprehension here - just consistent. > > 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. > +1 > > 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. Let's aim to patch what we can in the runup to 2.2 but not hold the release for final resolution to both of these issues. > MATH-408 This one needs to be fixed. Honestly, we should not have released this code without validation tests. My bad. Patches are most welcome. I will do this using R if we don't get any patches in the next couple of weeks. > and MATH-420 This one is easy and I will fix it in the next couple of days. > 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. Would appreciate others' opinions on this in the ticket. Looks to me like our code matches the spec, so I am leaning toward INVALID; but I may be wrong. MATH-385, MATH-384 Pretty much done by Mikkel. Comments on tickets welcome. We should be able to get this in. > , MATH-364, > Nice enhancement and patch, but no IP clearance, so probably best to push out to 3.0 unless someone is able / has bandwidth to clean room this and add validation tests. > MATH-228 Close to done by Mikkel. Review and comments welcome! > (mostly on the list, not as Jira comments). I'll have a look at > MATH-414. > So will I. Probably can effectively truncate. > > 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 ? > +1 for repackaging 3.0 code and a push to get 2.2 out ASAP. Phil > > best regards, > Luc > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
