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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
