You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: TSF/trustable/assertions/TA-CONSTRAINTS_CONTEXT.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -78,15 +78,15 @@ contradictions and obvious pitfalls within the defined Statements.
78
78
-**Answer**: The existing set of AOUs provides effective guidance for consumers.
79
79
- Do they provide clear guidance for upstreams on reusing components with
80
80
well-defined claims?
81
-
-**Answer**:
81
+
-**Answer**: # currently unclear how to interpret this question
82
82
- Are any Statements explicitly designated as not reusable or adaptable?
83
-
-**Answer**:
83
+
-**Answer**: No, all statements could theoretically be adapted or reused.
84
84
- Are there worked examples from downstream or upstream users demonstrating
85
85
these constraints in practice?
86
86
-**Answer**:
87
87
- Have there been any documented misunderstandings from users, and are these
88
88
visibly resolved?
89
-
-**Answer**:
89
+
-**Answer**: Yes, it is documented that the [brace initialisation](https://json.nlohmann.me/home/faq/) (cf. AOU-06) regularly leads to confusion, cf. [here](https://github.com/nlohmann/json/issues/4898).
90
90
- Do external users actively keep up with updates, and are they properly
91
91
notified of any changes?
92
92
-**Answer**: External users of the library are not necessarily automatically notified of an update, and are neither assumed nor required to keep up to date. If the external user forks the github repository, however, then github shows automatically whenever the upstream changes.
In eclipse-score/inc_nlohmann_json, a GitHub workflow continuously monitors the fraction of failing unit and integration tests on protected branches (e.g., main, release branches). If the failure rate exceeds a defined threshold over a configurable number of consecutive runs, the workflow blocks further merges to the affected branch, and restores the last known-good commit (last fully passing pipeline) as the default basis for integration and release.
In eclipse-score/inc_nlohmann_json, a GitHub workflow tracks CI pipeline duration (build + tests) over time. If the median runtime increases beyond a defined relative threshold compared to a rolling baseline, the workflow flags the regression, blocks releases from the affected commit(s), and
7
+
opens or updates an issue to investigate performance-related misbehaviours.
In eclipse-score/inc_nlohmann_json, code coverage for unit and integration tests is measured on each CI run. If coverage for any protected branch decreases by more than a defined threshold relative to the previous release baseline, the workflow blocks merges that introduce the regression, and requires either a compensating test update or a documented justification approved by a Subject Matter Expert.
In eclipse-score/inc_nlohmann_json, dependency and CVE status (including GitHub security alerts and Dependabot alerts) is monitored continuously. The presence of any unresolved critical or high-severity vulnerability relevant to nlohmann/json usage blocks new releases and integration of new changes triggers an issue or misbehaviour entry with mitigation actions (update, patch, or justified dismissal), and is tracked until mitigation is implemented and verified.
In eclipse-score/inc_nlohmann_json, the rate of newly reported misbehaviours or bugs attributable to nlohmann/json (within S-CORE’s use cases) is tracked for each new version integrated. If the rate over a defined observation window exceeds a specified threshold compared to previous versions the affected version is no longer considered a known-good state integration is rolled back to the last known-good version.
0 commit comments