Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[core] Adopt JApiCmp to enforce control over API changes #494

Closed
jsotuyod opened this issue Jul 10, 2017 · 4 comments · Fixed by #4926
Closed

[core] Adopt JApiCmp to enforce control over API changes #494

jsotuyod opened this issue Jul 10, 2017 · 4 comments · Fixed by #4926
Assignees
Labels
a:suggestion An idea, with little analysis on feasibility, to be considered
Milestone

Comments

@jsotuyod
Copy link
Member

The library (also available as a stand alone tool and a Maven plugin) checks the binary differences between 2 JARs.

This can allow us to enforce compliance with semantic versioning.

https://github.com/siom79/japicmp

@jsotuyod jsotuyod added the a:suggestion An idea, with little analysis on feasibility, to be considered label Jul 10, 2017
@oowekyala
Copy link
Member

There's also a sonarqube plugin, maybe that could be nice to have feedback on PRs.

In any case I think this would be really useful on the Maven build. The setup doesn't appear terribly complicated, I could try that shortly.

@adangel
Copy link
Member

adangel commented Mar 11, 2018

There is also https://revapi.org/ as an alternative.

@adangel adangel added this to the 7.0.0 milestone Oct 28, 2020
@adangel adangel self-assigned this Oct 30, 2020
@adangel
Copy link
Member

adangel commented Oct 31, 2020

I've tried out now both japicmp and revapi (actually on the current master branch).

japicmp is easier to use (hence I could easily compare older versions), revapi looks more sophisticated.

One incompatibility, that revapi found on master (6.30.0-SNAPSHOT <-> 6.29.0) are these two changes:



With #2872 we changed the return type from "Object" to "Node". This is Method Return Type Changed Covariantly which apparently is a binary incompatibility. Both classes however are annotated with @InternalApi. Is this Ok? I've configured revapi to ignore all changes, if the classes are annotated that way... Is this correct on 6.x?

Next steps:

  • let revapi compare older versions and create some reports
  • test with pmd7 - here we need to compare against the latest 6.x version... and since we have a major version change, no incompatibility should be detected.

FYI @oowekyala

@adangel
Copy link
Member

adangel commented Nov 18, 2022

Note: There is now also https://github.com/alien-tools/breakbot, see https://github.com/breakbot-playground/pmd/pull/2/checks for a sample report

@adangel adangel modified the milestones: 7.0.0, 7.x Jan 23, 2023
@adangel adangel modified the milestones: 7.x, 7.1.0 Apr 4, 2024
@adangel adangel changed the title [core] Adopt JApiCmp to enforce control over API changes [misc] Adopt JApiCmp to enforce control over API changes Apr 4, 2024
@adangel adangel changed the title [misc] Adopt JApiCmp to enforce control over API changes [core] Adopt JApiCmp to enforce control over API changes Apr 4, 2024
adangel added a commit to adangel/pmd that referenced this issue Apr 4, 2024
@adangel adangel mentioned this issue Apr 4, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:suggestion An idea, with little analysis on feasibility, to be considered
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants