Jörg Schaible schrieb: >>> 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. >>> >>> - Jörg >>> >>> >> I 'd be happy to do it this way, but I am skeptical whether such a >> policy can actually be established. You know how hard it is >> to convince >> people to vote +1 for a release. If clirr claims that there >> is a binary >> incompatible change, chances a pretty good that you get a veto. >> > > Clirr is used to detect unintentional binary incompatibility. If we document > the facts (in site documentation and javadoc) everybody is informed and > should not be surprised if we actually follow this agenda. If a new version > is enhancing the Configuration interface then, the release manager should > state this fact in release notes and vote call by documenting the *expected* > clirr result with a pointer to the agreement that is used as basis for the > incompatibility. IMHO this should be enough. Following either the interface > or the abstract class approach has its downside. Maybe such a combination > will give you the pros of both worlds. > So the rule would be: * the project provides both an interface and an abstract class that implements that interface. * code that *uses* the API should always use just the interface, ie *call* methods via the interface and pass instances around as the interface type * code that *implements* the API should always subclass the base class.
The project reserves the right to add methods to the interface, but will always provide a concrete default implementation on the abstract subclass. Methods will *not* be added to the interface if a sensible default implementation cannot be provided. That sounds like a pretty good approach to me; seems to ensure maximum backward compatibility while keeping a clean interface-based API (which allows interface-based proxies to be generated at runtime). I would agree with Jörg here, that as long as release-notes document expected clirr incompatibilities there is no problem. Clirr can of course be configured to ignore specific classes when processing... Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
