commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikkel Meyer Andersen <>
Subject Re: [math] 2.2 compatibility issues
Date Sun, 02 Jan 2011 18:42:18 GMT

In general: I understand that removing e.g. functions to an interface
is (seriously) breaking compatibility. Why is it just as bad to add
e.g. functions to an interface? As far as I know, the binaries are
still compatible, so where does this "adding breaks compatibility"
stem from? And is it only in interfaces and abstract classes, or is it
also in implementing classes (such as implemented probability
distributions)? Sorry if these are stupid questions or stuff I ought
to know.

2011/1/2 Phil Steitz <>:
> The clirr report run from the current MATH_2_X branch is, as expected,
> problematic.  To get 2.2. out, we need to agree on what breaks we are going
> to allow and what we are going to fix.   Here is a first cut and proposal
> for some immediate fixes that I would appreciate feedback on.
> 0)  The improvements to the distributions classes to add characteristic
> support and positive mass domains have added some new methods to interfaces
> and new abstract methods to abstract classes.  I apologize for not spotting
> this in initial patch reviews or being clear in discussion of the
> features.   I think we can keep the functionality without introducing the
> compatibility breaks by removing the added methods from interfaces /
> abstract classes.  The only painful part is the nice solution for caching
> numerical characteristics that will have to be repeated in the
> implementation classes that need it.  I would like to proceed with these
> changes in the 2.2 branch if others are OK with it.
I'll also apologize for not realising my solution broke compatibility.
I'm okay with your workaround, if we are not just pushing the
functionality to 3.0?
> 1) Removed superclasses in the exception hierarchy.  I am OK leaving these
> as is.
> I don't know what, if anything, to do about the following:
Me neither. If they are truly incompatible, are the only options then
to either break compatibility or push to 3.0?
> 2) Changed return type of interpolate in BicubicSpline.
> 3) Incompatible changes in the ode package.
> 4) Incompatible changes in the optimization package.
> Thanks in advance!
> Phil

Cheers, Mikkel.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message