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... WDYT? Many thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Sep 5, 2011 at 5:52 AM, Matt Benson <gudnabr...@gmail.com> wrote: > On Sun, Sep 4, 2011 at 7:02 PM, sebb <seb...@gmail.com> wrote: >> On 4 September 2011 20:04, Simone Tripodi <simonetrip...@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-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 >> >> > > --------------------------------------------------------------------- > 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
