Apache NiFi 2.6.0 upstream ships with Angular 19.2.14. Apache did not change the Angular dependency within the NiFi 2.6.x release line. Instead, the Angular dependency update was introduced as part of the NiFi 2.7.0 development cycle. In contrast, CFM modified the Angular dependency while continuing to ship NiFi 2.6.0. CFM 4.12.0.0 upgraded Angular from 19.2.14 to 19.2.19. After this change, the frontend no longer sent the Request-Token header with API requests, causing NiFi’s XSRF protection to reject legitimate UI operations. This regression was later addressed in CFM 4.12.0.1. However, instead of remaining on the Angular 19.x patch line, CFM 4.12.0.1 upgraded Angular again to 20.2.4. After inspecting the compiled frontend bundled with CFM 4.12.0.1, I confirmed that it is built with Angular 20.2.4. I also verified that the bundled frontend still follows the pre-fix implementation for GHSA-58c5-g7wp-6w37 and does not contain the upstream security fix. According to Angular’s official security advisory, Angular 20.2.4 is also below the first fixed Angular 20 release (20.3.14). From a release engineering perspective, this dependency strategy is difficult to understand. Apache chose not to introduce this dependency change into the NiFi 2.6.x release line. Instead, it was delivered as part of NiFi 2.7.0, allowing the framework update to be integrated and validated together with the rest of the release. In contrast, CFM introduced major frontend dependency changes into a maintenance release based on NiFi 2.6.0. This not only introduced a functional regression in 4.12.0.0, but also further diverged from the Apache NiFi upstream while selecting an Angular version that still does not contain the official upstream security fix. Could you please explain the rationale behind this dependency strategy? ... View more