On 11 January 2012 13:18, Christian Grobmeier <grobme...@gmail.com> wrote: > 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
As a separate thread please. >> >>> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org