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

Reply via email to