It's not a new method, it's a change of signature. The old method is still there. If an implementation disregards the abstract class, which contains the replacement, it would still work, right?
Gintas 2017-07-28 18:55 GMT+02:00 Stefan Bodewig <bode...@apache.org>: > On 2017-07-28, Jaikiran Pai wrote: > > > Ivy has a DependencyResolver interface which is the central piece of > > contract/interface for extending Ivy (any external usage for that > > matter). > > I'm not at all familiar with Ivy and the eco system that might exist > around it. How likely is it that anybody has implemented this interface > in a an extension? And how likely does such an extension not subclass > AbstractResolver? > > Adding methods to an interface usually means a backwards incompatible > change that requires a new major version when using semantic versioning > (not sure whether Ivy uses semver, Ant itself doesn't). > > > Instead, what I think we could do is add that method to the > > implementing class(es) internally (like the AbstractResolver - the PR > > does that already). Of course at some places within our code, if we > > want to use the newer generics based method, we will probably end up > > doing a type check on the resolver instance to see if it's a > > AbstractResolver which has that new method, but I think that should be > > fine for now. > > Alternatively add a new interface with that method that extends > DependencyResolver and is implemented by AbstractResolver and check for > the new interface rather than AbstractResolver? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
