I think that the suggestion is to preserve the old signatures in 3.0, but have them not only be deprecated but also throw an error. This is an incompatible change that can't really be done in a point release. Simply removing the old signatures makes it harder to track down the problem. Preserving the old signatures for error trapping only allows precise error feedback of the form "We told you not to do this in 2.2, now we mean it!".
I think that that suggestion to preserve the old signature for error trapping is an excellent one. It doesn't need to be done forever and removing the error throwing variants needn't be considered an API change. On Wed, Dec 1, 2010 at 4:42 PM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > > > In order to avoid nasty surprises, what about having these "old" > > > constructors deprecated and throw a "MathUnsupportedOperationException" > in > > > 3.0 and remove them in 3.x? [This is an incompatible change but the > > > exception throwing will make it sure that nobody can actually depend on > this > > > constructor.] > > > > No, we can deprecate them as early as 2.2 and remove them in 3.0, just > > as the other changes we already did. > > But... in 2.2, the new code (contructors with 2 tolerances as parameters) > does not exist, and in 3.0, the old code (constructor with a > "maxIterations" > and tolerance parameters) does not exist. > So indeed, this former constructor should be deprecated (in 2.2) but there > is nothing to remove (in 3.0). And still, code that uses the old interface > with the new library will fail, as you described. [Or I didn't understand > what the problem is, or the proposed solution...]
