Some design goals:
- Get the important information (summary: what's broken? what's the impact?) at a glance
- Full details available (client by client, statement by statement, etc.)
- 'Obscure' terminology (kinds of BCs, use types, etc.) should be documented (e.g., links to an external documentation)
- Source code references (breaking declarations, broken statements in client code, etc.) should point to the actual code on GitHub
- TODO: check GitHub Checks' annotations API (can we weave BCs/detections directly in source code listings?)
This pull request introduces 3 breaking changes, causing 16 detections in client code. 2 of 3 clients are impacted by the changes (66%).
Status | Declaration | Kind | Impacted clients |
---|---|---|---|
❌ | spoon.A |
CLASS_LESS_ACCESSIBLE |
1 (SpoonLabs/nopol) |
❌ | spoon.B#m() |
METHOD_REMOVED |
2 (SpoonLabs/nopol, SpoonLabs/flacoco) |
✔️ | spoon.B#f |
FIELD_NOW_FINAL |
0 |
Status | Client | Detections |
---|---|---|
❌ | SpoonLabs/flacoco | 5 |
❌ | SpoonLabs/nopol | 11 |
✔️ | SpoonLabs/coming | 0 |
Location | Code | Breaking declaration | Kind | Use Type |
---|---|---|---|---|
X.java:11 |
flacoco.X | spoon.A |
CLASS_LESS_ACCESSIBLE |
EXTENDS |
Y.java:23-31 |
flacoco.Y#a() | spoon.B#f |
FIELD_NOW_FINAL |
FIELD_ACCESS |
Z.java:112-118 |
flacoco.Z#b() | spoon.B#m() |
METHOD_REMOVED |
METHOD_INVOCATION |
...
...