david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 09:32:08 -06:00
parent e604115335
commit 27b86158a6
10 changed files with 164 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
vault/03-context/workstreams/consumer-integration.md
View File

@@ -3,9 +3,9 @@ type: workstream
project: fidelity
status: active
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
work-items: [pdiap-14859, pdiap-15836]
related: [xflow-swiftui-migration, xflow-debugging]
updated: 2026-04-16
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
updated: 2026-04-17
tags:
- workstream
- fidelity
@@ -30,15 +30,65 @@ Capture the durable release and validation path between XFlow changes and real c
---
## Current Release Propagation Model
- The current release path is usually:
- `pr100660-xflow-for-ios` releases XFlowSDK
- `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release
- `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version
- downstream consumer release then determines when the change reaches the App Store build
- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
- Fid4 currently consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.
---
## Step-By-Step Propagation
1. Release XFlowSDK from `pr100660-xflow-for-ios`.
- Jenkins pipeline: `xflow-for-ios-publish`
- Produces the XCFramework artifact
- Publishes to internal Fidelity Artifactory at `artifactory.fmr.com`
- Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x`
- After publication, consumers can adopt the new SDK version through CocoaPods
2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`.
- XFlowViewMaker lives in `Adapters/XFlowViewMaker`
- Update the XFlowViewMaker podspec to the new XFlowSDK version
- Run `tuist generate -n`
- Run `pod install`
- Open a PR and get required approvals
- Ping code owners when protected-branch approval is the remaining blocker
- After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter
- That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0`
- Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main`
3. Update Fid4 in `ap010981-ios-flagship-app`.
- Modify the Podfile to consume the new XFlowViewMaker version
- Run `tuist generate -n`
- Run `pod install --repo-update`
- Open a PR and get approvals
- After merge, the consumer team owns the final application release to the App Store
---
## Investigation Rules
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream.
- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient.
- Separate these failure modes:
- SDK bug
- adapter/version propagation issue
- protected-branch or code-owner approval delay
- publish pipeline failure or auto-versioning surprise
- FT module publish/test issue
- consumer app setup or pipeline issue
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort.
- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo.
- The fastest reliable signals are:
- fixed version references in the Podfile when present
- archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files
- Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
---