Merci pour le partage, @lvc !

Pour JUnit 5, je me demandais s'il existait un moyen de personnaliser ce que l'outil considère comme une API publique. Nous avons une annotation @API pour marquer les classes publiques comme internes, obsolètes, maintenues, stables, etc. Existe-t-il un moyen d'exclure le code interne de l'analyse ?

C'est fantastique @lvc

Un moyen d'inclure le code dans notre branche principale dans le rapport ? J'aimerais voir quels changements incompatibles nous aurions entre la 4.12 et la 4.13 si nous sortions aujourd'hui.

@kcooney ,

Un moyen d'inclure le code dans notre branche principale dans le rapport ? J'aimerais voir quels changements incompatibles nous aurions entre la 4.12 et la 4.13 si nous sortions aujourd'hui

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

L'instantané est tiré de : https://oss.sonatype.org/content/repositories/snapshots/junit/junit/

Le rapport est mis à jour quotidiennement. Soyez prudent lors de la lecture du rapport en raison de possibles faux positifs.

Merci.

@marcphilipp ,

Existe-t-il un moyen d'exclure le code interne de l'analyse ?

Besoin de temps pour apprendre à https://github.com/lvc/japi-compliance-checker à distinguer les paramètres d'annotation avant de filtrer par une valeur de paramètre...

Merci.

Il semble que le seul changement décisif soit le n°1245

1421 est également techniquement un changement décisif (incompatibilité de source) mais personne ne devrait appeler External Resource.after()