History of API changes for JUnit

[lvc]

Hello,

I'd like to share report on API changes and backward compatibility for the JUnit library: https://abi-laboratory.pro/java/tracker/timeline/junit/

Report for JUnit5: https://abi-laboratory.pro/java/tracker/timeline/junit-jupiter-api/

BC — binary compatibility
SC — source compatibility

The report is generated according to the article https://wiki.eclipse.org/Evolving_Java-based_APIs_2 by the https://github.com/lvc/japi-tracker tool.

Hope it will be helpful for users and maintainers of the library.

Thank you.

[marcphilipp]

Thanks for sharing, @lvc!

For JUnit 5 I was wondering if there is a way to customize what the tool considers public API. We have a custom @API annotation to mark public classes as internal, deprecated, maintained, stable etc. Is there a way to exclude internal code from the analysis?

[kcooney]

That's fantastic @lvc

Any way to include the code in our master branch in the report? I would love to see what incompatible changes we would have between 4.12 and 4.13 if we released today.

[lvc]

@kcooney,

Any way to include the code in our master branch in the report? I would love to see what incompatible changes we would have between 4.12 and 4.13 if we released today

Done: https://abi-laboratory.pro/java/tracker/timeline/junit/

The snapshot is taken from: https://oss.sonatype.org/content/repositories/snapshots/junit/junit/

The report is updated daily. Please be careful when reading the report due to possible false positives.

Thank you.

[lvc]

@marcphilipp,

Is there a way to exclude internal code from the analysis?

Need some time to teach https://github.com/lvc/japi-compliance-checker to distinguish annotation parameters before filtering by a parameter value...

Thank you.

[panchenko]

It seems like the only breaking change is #1245

[kcooney]

#1421 is also technically a breaking change (source incompatibility) but no one should call External Resource.after()