Hi Oliver, Oliver Heger wrote: > Jörg Schaible schrieb: >> Hi,
[snip] >> 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. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
