Hi devs,
Right now our build breaks on 3 types of incompatibilities (thanks to Revapi):
- Binary
- Source
- Semantic
In addition we break on “potentiallyBraking” severities. See https://revapi.org/modules/revapi-java/index.html to see the list of 80+ checks done by Revapi if you’re interested.
To understand how it works, check the “adding a annotation” check for example. It’s defined as:
Binary severity: equivalent
Source severity: equivalent
Semantic severity: potentially breaking
Note that “equivalent” severity is below “potentiallyBreaking” and thus don’t fail the build. So when an annotation is added, it breaks our build because it’s a semantic incompatibility of severity “potentiallyBreaking”.
So on https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwardCompatibility we have not been very precise and the goal of this VOTE is to do so.
This VOTE is about these rules:
- Break on binary incompatibilities
- Break on semantic incompatibilities (note: we need to review all these checks in the future to see if we really want them all but for now we know we need the annotation ones at least since they can be problems and change behaviors in an important way).
- Don’t break on source incompatibilities. Rationale: it’s too strict and we want to be able to change code (like add missing generics to return types) without breaking the build and having to put ignores (which is what we do most of the time ATM). Note that @tmortagne has suggested that source incompatibility changes won’t break any Groovy scripts that could be used in user’s wiki or in extensions since Groovy uses reflection to call methods.
WDYT?
Here’s my +1
Thanks
-Vincent