Jörg Schaible a écrit :
IMHO we should define what we want to reach. Adding a method to an interface does not break *binary* compatibility of existing code. The method is simply not called. However, a client will have to implement the new method, if CConf is a compile time dependency *and* he uses an implementation not delivered by CConf. Maybe it is the best approach to have an abstract base class and the interface. We have to tell our users, that they should extend from the abstract class if they want to ensure backward compatibility for own implementations of the Configuration interface. Point is, that it *is* only an advice/recommendation and something like clirr will always report a violation in compatibility. Hoiwever, it is our desicion how we should proceed.
Late comment on this topic, I agree with Jorg's proposal. I was a proponent of the abstract class approach, but if we keep the freedom of modifying the interface that's fine.
If we all agree on this, the corollary is that we could start enhancing the Configuration interface on the 1.x branch, right?
Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
