commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [chain][v2] updated clirr report
Date Mon, 05 Sep 2011 08:14:59 GMT
Hi Seb,
thanks a lot for your feedbacks!!!

All Clirr errors you can see on the report - except the `retrieve`
added method in the Context interface - are strictly related to
internal data structures/class fields, that were initially made as
protected so, as checkstyle suggested, I reduced the visibility and
added the accessor methods - I forgot to mark some with the @since
tag, going to add as soon as I get a spare time slot.

So, I join Matt on asserting that these modifications are minor and
could be considered backward compatible in
spirit, I would call a vote to move the current trunk in a 1_X branch
and move the current 2.0-work branch in trunk, and evolving the
component directly from there.
We also estimated junit test update and better component
modularization, that IMHO could be applied directly on trunk...

Many thanks in advance, have a nice day!

On Mon, Sep 5, 2011 at 5:52 AM, Matt Benson <> wrote:
> On Sun, Sep 4, 2011 at 7:02 PM, sebb <> wrote:
>> On 4 September 2011 20:04, Simone Tripodi <> wrote:
>>> Hi all guys,
>>> the clirr report has just been updated on my personal ASF space[1],
>>> can you review please?
>> As it stands, 2.0 is not strictly binary compatible with 1.2.
>> However, it depends whether the changes affect the published API, or
>> are internal changes that should not affect external code.
>> For example, the "commands" field - is there a use case for external
>> code? Or is just an implementation detail?
>> I don't know the code or how it is used, so it is difficult to say,
>> but IMO there are some binary incompatibilities that can be ignored.
>> e.g. the old code defined a string field that was supposed to be
>> constant, but failed to use final. If there is no valid use case for
>> changing the value of the constant, then I think there is a case for
>> allowing that, even though it is not strictly compatible - if code
>> does write to the field then that code is broken anyway.
> I'm not sure if any active Commons developers know the code from a
> user perspective--at least, no one has spoken up to that effect.  From
> my own outsider's perspective, the apparent relative lack of
> popularity of the component, in addtition to the nature of the
> component and the nature of the changes made thus far, indicates that
> these are minor and could be considered backward compatible *in
> spirit*.  I don't think there should be any dispute over whether the
> branch code can become the basis of [chain]'s trunk (so my implicit +1
> on that score); only whether repackaging, etc., are necessary.  On the
> one hand, there is something to be said for consistency, which would
> suggest that a report of incompatibility by clirr automatically
> triggers repacking/GAV .  However, AIUI we have *not* required such a
> hard-and-fast rule for all components, and given that fact the
> proposed changes would seem to me minor enough to justify a major
> version bump only.
> Matt
>>> I think it's time to call a vote to accept the current branch as the
>>> trunk, WDYT?
>>> Many thanks in advance, have  anice day!
>>> Simo
>>> [1]
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message