Check for binary compatibility during Maven (or CI) build
envgap__google__gson-2171
01 / FAILURE SIGNATURE
As reported upstream
Breaking changes should either cause an error or at least a warning, ideally with GitHub annotation for the code causing the issue. Optionally it might be useful to also generate a report which can be obtained as GitHub workflow artifact, showing the binary API differences. This could be useful to detect accidentially exposed methods or fields.
Not a benchmark task.
- The project already builds and runs before the fix, so there is nothing to repair.
02 / ENVIRONMENT RECIPE
- Base commit
f7a164d98b77d7f7e3f918115781e74fdede5bdb- Manifest
pom.xml- Reproduce
Awaiting issue-specific recipe- Run under trace
Awaiting a meaningful runtime command
03 / ORIGINAL ISSUE TEXT
google/gson #2171 · read the original issue
# Problem solved by the feature As seen in https://github.com/google/gson/pull/2169#issuecomment-1207197608, one can easily by accident break binary backward compatibility, for example by changing the return type of a method. # Feature description Either as part of a regular Maven build, or at least triggered by the CI, a check for binary compatibility should be performed. Breaking changes should either cause an error or at least a warning, ideally with GitHub annotation for the code causing the issue. Optionally it might be useful to also generate a report which can be obtained as GitHub workflow artifact, showing the binary API differences. This could be useful to detect accidentially exposed methods or fields. It appears there are multiple tools and Maven plugins for this; some of them are: - https://github.com/siom79/japicmp - https://github.com/revapi/revapi # Alternatives / workarounds Do nothing and review pull requests thoroughly to not break binary compatibility by accident?
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]