Danke fürs Teilen, @lvc!

Für JUnit 5 habe ich mich gefragt, ob es eine Möglichkeit gibt, das anzupassen, was das Tool als öffentliche API betrachtet. Wir haben eine benutzerdefinierte @API Annotation, um öffentliche Klassen als intern, veraltet, gewartet, stabil usw. zu markieren. Gibt es eine Möglichkeit, internen Code von der Analyse auszuschließen?

Das ist fantastisch @lvc

Gibt es eine Möglichkeit, den Code in unserem Master-Zweig in den Bericht aufzunehmen? Ich würde gerne sehen, welche inkompatiblen Änderungen wir zwischen 4.12 und 4.13 hätten, wenn wir heute veröffentlichen würden.

@kcooney ,

Gibt es eine Möglichkeit, den Code in unserem Master-Zweig in den Bericht aufzunehmen? Ich würde gerne sehen, welche inkompatiblen Änderungen wir zwischen 4.12 und 4.13 hätten, wenn wir heute veröffentlichen würden

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

Der Snapshot stammt von: https://oss.sonatype.org/content/repositories/snapshots/junit/junit/

Der Bericht wird täglich aktualisiert. Bitte seien Sie vorsichtig beim Lesen des Berichts wegen möglicher Fehlalarme.

Dankeschön.

@marcphilipp ,

Gibt es eine Möglichkeit, internen Code von der Analyse auszuschließen?

Brauchen Sie etwas Zeit, um https://github.com/lvc/japi-compliance-checker beizubringen, Annotationsparameter zu unterscheiden, bevor Sie nach einem Parameterwert filtern...

Dankeschön.

Es scheint, dass die einzige bahnbrechende Änderung #1245 ist

1421 ist auch technisch gesehen eine Breaking Change (Quelleninkompatibilität), aber niemand sollte External Resource.after() aufrufen