شكرا للمشاركة ، 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()