feat: Update work items and documentation for improved release propagation clarity and system dependencies

This commit is contained in:
2026-04-17 09:32:08 -06:00
parent e604115335
commit 27b86158a6
10 changed files with 164 additions and 18 deletions

View File

@@ -3,8 +3,8 @@ type: system
project: fidelity
status: active
workstreams: [consumer-integration, xflow-swiftui-migration]
related: [xflowsdk, fid4, ftframeworks, pdiap-14859, pdiap-15836]
updated: 2026-04-16
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
updated: 2026-04-17
tags:
- system
- fidelity
@@ -22,6 +22,23 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework
- Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible.
- XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout.
- Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions.
- XFlowViewMaker currently lives in the monorepo `PR100660-ios-frameworks` under `Adapters/XFlowViewMaker`.
---
## Release Mechanics
- When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change.
- The common release flow is:
- update the XFlowViewMaker podspec to the new XFlowSDK version
- run `tuist generate -n`
- run `pod install`
- open a PR
- wait for required approvals, including protected-branch/code-owner approval when applicable
- merge, often through automerge once approvals are complete
- let the Jenkins pipeline `publish-XFlowViewMaker` publish the adapter release
- `publish-XFlowViewMaker` usually auto-detects the next version and commonly increments the minor version automatically.
- The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on `main`.
---
@@ -29,6 +46,7 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework
- When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption.
- If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`.
- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
---