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. 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
