commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] incompatible change in r936295
Date Tue, 01 Jun 2010 23:10:59 GMT
Gilles Sadowski wrote:
> Hi.
> 
>> Some compiled client code can break if it extends the method, and
>> returns something which is a BivariateRealFunction, but not a
>> BicubicSplineInterpolatingFunction.
>> Since the super class method contract has changed, the client code
>> does not respect the contract (return
>> BicubicSplineInterpolatingFunction) any longer.
>> Hence the break.
> 
> Thanks for the explanation.
> 
> OK. So there is indeed an incompatible change between 2.1 and current (to
> become 2.2). Is this really a problem? I mean, it could be seen as a bug
> fix (i.e. it was a mistake to return the super-class type)!
> Does the policy forbid such kind of fixes even if prevents the development
> of CM code that depends on these fixes?

What exactly does postponing this change prevent?  Why can't we just
cast the return if necessary?  The class itself is deprecated, to be
removed I assume in 3.0, so I don't see much risk in our casting
return types internally in the interim.  Am I missing something here?

> 
> As I've already proposed for another compatibility breaking fix, can't we
> set up a poll on the "user" ML in order to assess the *real* damage that
> the modification will entail?

First, we can't count on the fact that all or impacted users are
subscribed to the user list.  Second, we have a policy that .x
releases should be drop-in replacements, which means they need to be
source and binary compatible.  Users who "drop in" a replacement
with a method signature change without recompiling all linked code
will get runtime exceptions when they invoke the changed method -
even if the change is "harmless" for them.  That was James' point.

We can certainly talk about changing the Commons versioning policy
to allow incompatible changes in .x releases; but until we agree to
do that, we need to do our best to comply.

Phil
> 
> 
> Gilles
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message