Hi devs,
We currently break the build on binary and semantic incompatibilities. There are 4 types of cases I can see:
- Real breakages that we still want to do but the users need to be warned since existing code using these APIs will or may fail at runtime.
- Real breakages but happening on
@Unstable
code. - Semantic changes that are
potentially breaking
inseverity
(like adding an annotation) but that, after analyzing we consider to not be a breakage. - Revapi bugs or limitations, that are not breakages in our opinion
I’m proposing to use the criticality
feature of revapi to differentiate them when adding the differences
items in our pom.xml
, as follows:
- For 1), use the
highlight
criticality - For 2), use the
documented
criticality - For 3) and 4), use the
allowed
criticality
Then, the {{backwardCompatibilityReport134/}}
macro would be modified to display highlight
and documented
in two different lists, and to skip allowed
ones (i.e. they would not be shown to the user at all).
WDYT?
Thanks