Спасибо, что поделились, @lvc!

Для JUnit 5 мне было интересно, есть ли способ настроить то, что инструмент считает общедоступным API. У нас есть специальная аннотация @API для пометки общедоступных классов как внутренних, устаревших, поддерживаемых, стабильных и т. Д. Есть ли способ исключить внутренний код из анализа?

Это фантастика @lvc

Есть ли способ включить код из нашей основной ветки в отчет? Я хотел бы увидеть, какие несовместимые изменения были бы у нас между 4.12 и 4.13, если бы мы выпустили сегодня.

@kcooney ,

Есть ли способ включить код из нашей основной ветки в отчет? Мне бы хотелось увидеть, какие несовместимые изменения были бы у нас между 4.12 и 4.13, если бы мы выпустили сегодня

Готово: https://abi-laboratory.pro/java/tracker/timeline/junit/

Снимок взят из: https://oss.sonatype.org/content/repositories/snapshots/junit/junit/

Отчет обновляется ежедневно. Пожалуйста, будьте осторожны при чтении отчета из-за возможных ложных срабатываний.

Спасибо.

@marcphilipp ,

Есть ли способ исключить внутренний код из анализа?

Нужно время, чтобы научить https://github.com/lvc/japi-compliance-checker различать параметры аннотации перед фильтрацией по значению параметра ...

Спасибо.

Похоже, единственное критическое изменение - # 1245.

1421 также технически является критическим изменением (несовместимость источников), но никто не должен называть External Resource.after()