3 May
2012
3 May
'12
9:55 a.m.
On May 3, 2012, at 9:35 AM, Thomas Mortagne wrote:
On Thu, May 3, 2012 at 9:23 AM, Vincent Massol
<vincent(a)massol.net> wrote:
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_-_Addi…
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
Hi Thomas,
On May 2, 2012, at 6:48 PM, GitHub wrote:
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. Branch: refs/heads/master
Home: https://github.com/xwiki/xwiki-commons
Commit: 6ecb131081233764ed773eb84f9be34e23edb888
https://github.com/xwiki/xwiki-commons/commit/6ecb131081233764ed773eb84f9be…
Author: tmortagne <thomas.mortagne(a)gmail.com>
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. > 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