On 24 November 2010 10:45, Luc Maisonobe <luc.maison...@free.fr> wrote: > Le 24/11/2010 11:34, sebb a écrit : >> On 24 November 2010 09:38, 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. >>> >>> 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 ;-) >> >> If the API is incompatible, changing the package name is essential IF >> there are likely to be multiple dependencies on Math. > > Yes. There is one big research project split into many components > developed by different unsynchronized teams throughout the world. > Commons-math is one of their dependencies. > > I'm pretty sure some components are already using 3.0 (well, they have > committers here ...) and also some other teams are still stuck with 2.1. > With different package names, it will probably help them transition at > their own pace before everyone is in sync again (if it ever happens ...) > >> >> Note that Clirr does not have an option to treat different package >> names as being the same code line (AFAIK). >> >> So consider changing the package names just before release to make it >> easier to run Clirr in the meantime. > > Thanks for the hint. As we already know we have introduced > incompatibilities, is a Clirr report still useful ? >
Yes - it can be used to know where to add the @since markers. It would also be useful when documenting which APIs have changed. Updating user code is generally going to involve more than just changing the package name and recompiling. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
