On Wed, Jan 11, 2012 at 1:55 PM, sebb <seb...@gmail.com> wrote: > On 11 January 2012 11:42, Christian Grobmeier <grobme...@gmail.com> wrote: >> On Tue, Jan 10, 2012 at 9:06 PM, sebb <seb...@gmail.com> wrote: >>>> The list is pretty concrete. >>>> It does not say anything on binary compatibility (or i didn't find it). >>> >>> "Release B is said to be fully-compatible with Release A if B can >>> simply replace A in (nearly) all circumstances and deployments without >>> changing the client code or configuration, and without changing the >>> semantics of any public or protected member. " >> >> And: >> >> "Generally speaking, a fully-compatible change will at most change the >> private interface of a component, or simply add classes, methods and >> attributes whose use is optional to both internal and external >> interface clients." >> >> Have we defined internal/external interfaces for [email] or other >> components? How are they defined? Are they excluded from the clirr >> report? I think Henri brought that questions up already > > The setter methods at least are clearly external.
True. We should resurrect the discussion on "internal" package naming though > >> Cheers >> Christian >> >> -- >> http://www.grobmeier.de >> https://www.timeandbill.de >> >> --------------------------------------------------------------------- >> 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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
