On Thu, May 3, 2012 at 9:55 AM, Vincent Massol <[email protected]> wrote: > > On May 3, 2012, at 9:35 AM, Thomas Mortagne wrote: > >> On Thu, May 3, 2012 at 9:23 AM, Vincent Massol <[email protected]> wrote: >>> Hi Thomas, >>> >>> On May 2, 2012, at 6:48 PM, GitHub wrote: >>> >>>> Branch: refs/heads/master >>>> Home: https://github.com/xwiki/xwiki-commons >>>> Commit: 6ecb131081233764ed773eb84f9be34e23edb888 >>>> >>>> https://github.com/xwiki/xwiki-commons/commit/6ecb131081233764ed773eb84f9be34e23edb888 >>>> Author: tmortagne <[email protected]> >>>> Date: 2012-05-02 (Wed, 02 May 2012) >>>> >>>> Changed paths: >>>> M xwiki-commons-core/pom.xml >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/AbstractJob.java >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/Job.java >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/JobManager.java >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/event/status/JobStatus.java >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobManager.java >>>> M >>>> xwiki-commons-core/xwiki-commons-job/src/main/java/org/xwiki/job/internal/DefaultJobStatus.java >>>> >>>> Log Message: >>>> ----------- >>>> XCOMMONS-162: Add start and end data to job status >>>> XCOMMONS-163: Add join method to Job >>>> >>>> >>>> diff --git a/xwiki-commons-core/pom.xml b/xwiki-commons-core/pom.xml >>>> index 799f042..2251f94 100644 >>>> --- a/xwiki-commons-core/pom.xml >>>> +++ b/xwiki-commons-core/pom.xml >>>> @@ -115,6 +115,8 @@ >>>> <exclude>**/internal/**</exclude> >>>> <exclude>**/test/**</exclude> >>>> <!-- Remove the following excludes after we release the >>>> current version as final --> >>>> + <exclude>org/xwiki/job/Job</exclude> <!-- New methods --> >>>> + <exclude>org/xwiki/job/event/status/JobStatus</exclude> <!-- >>>> New methods --> >>> >>> This goes against the deprecation/legacy strategy we have voted since we >>> said we will not add *any* breakage. It's not allowed anymore to have any >>> exceptions in CLIRR. >>> (See http://markmail.org/message/tino4ngttflc5i3s). >>> >>> So you need to go through a deprecation strategy and move this to legacy. >> >> Did you really looked at what is the breakage ? I made sure it was >> clear but putting a <!-- New methods --> comment. If you have a >> solution to add new method to an interface without having to add a >> CLIRR exclusion please share. > > No I didn't really looked hard. I just took this opportunity to start the > thread about "Young" APIs (see my other email). > > Note that the change is breaking because you've added a new method to an API > that users can implement., See example4 in > http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method > > I'm pasting the reason here: > > " > Can adding an API method to a class or interface break compatibility with > existing Clients? > > If the method is added to an interface which Clients may implement, then it > is definitely a breaking change. > > If the method is added to a class (interface) which Clients are not allowed > to subclass (to implement), then it is not a breaking change. > > However, if the method is added to a class which Clients may subclass, then > the change should ordinarily be viewed as a breaking change. The reason for > this harsh conclusion is because of the possibility that a Client's subclass > already has its own implementation of a method by that name. Adding the API > method to the superclass undercuts the Client's code since it would be sheer > coincidence if the Client's existing method met the API contract of the newly > added method. In practice, if the likelihood of this kind of name coincidence > is sufficiently low, this kind of change is often treated as if it were > non-breaking. > " > > In other words if someone has already created code implementing the Job > interface for example and has published his work on extensions.xwiki.org (for > example) then when the new XE is released (with the new interface method) > this extension will not work anymore and the new change will this have broken > backward compatibility.
I know why it's breaking... > > Thanks > -Vincent > >>> Alternatively you should make a new proposal to amend our >>> backward-compatibility strategy for "young" apis. I'll start the thread for >>> you but in the meantime all Release Manager need to be very careful to not >>> perform new releases when there are CLIRR excludes since it means we have >>> broken backward compatibility. >>> >>> Thanks >>> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
