commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [chain][v2] updated clirr report
Date Mon, 05 Sep 2011 03:52:52 GMT
On Sun, Sep 4, 2011 at 7:02 PM, sebb <sebbaz@gmail.com> wrote:
> On 4 September 2011 20:04, Simone Tripodi <simonetripodi@apache.org> 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] http://people.apache.org/~simonetripodi/chain/clirr-report.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message