Phil Steitz <[EMAIL PROTECTED]> wrote: > I think that modulo some cleanup, testing and review and the one > dangling item below, we should be ready for a [math] release.
I first wanted to introduce SVD but now think I need to work more on this. This would delay a release for quite long. I therefore agree with you and propose to delay SVD to next release. > I will > RM if no one else wants to, but would appreciate it (and support by > sharing gruntwork) if someone else volunteers. I would be happy to help. However I never followed the release process before, so it may be to early for this one. Regardless of who manages the release, I will add the public subkey I have set up for releases signing in the KEYS file. > Here are some > questions to resolve in the release plan: > > 1. Is this 1.2 or 2.0? There is so much in the added Mantissa > classes that 2.0 makes sense from a functionality standpoint. On the > other hand, we have not broken backward compatibility with anything > (yet) and if we decide to go 2.0, we could consider some API change. > My vote is to keep compatibility in place, but still name it 2.0. I also think we should use 2.0 as the release number. There are some API changes as some methods have been deprecated. I also wonder if it would'nt be safer to change some unchecked exceptions to checked exceptions. An example for this is the solve method for UnivariateRealSover. Solvers may throw an IllegalArgumentException when the provided interval doesn't bracket the root for example. This is explained in javadoc but I would prefer to enforce it by replacing this by something like SearchIntervalException or even a broad SolverException. Of course, this would be break compatibility (but user code would be easy to fix). > 2. What if anything should we add to make "pluggability" as designed > in the library compatible with IOC frameworks? It won't work to add > setters for the main factories, since we use the static getInstance > factory pattern (see e.g. UnivariateRealSoverFactory). What might > make more sense would be to add setters for the individual solvers in > e.g. UnivariateRealSoverFactoryImpl. Any ideas on how best to attack > this? For those not familiar with [math] who may have ideas, the > basic setup is that we use abstract factories with static getInstance > methods that return concrete factories looked up using > commons-discovery. The concrete factories themselves source multiple > different object types . Adding setters seems a bit strange to me. I thought either we use abstract/concrete factories and let the user provide his own factories by extending the default one overriding only the factory method he need, or we use only one concrete factory and setters in the spirit of IOC. Providing both at the same time is confusing. I personally prefer the IOC way but once again this would be an incompatible change (this one is more difficult to fix in user code, but I'm not sure many people used this feature). Luc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
