paulb777
commented
4 days ago @mikehardy Thanks for the report
Firestore updates its gRPC dependencies only a few times a year - and we haven't yet built automation for keeping the binary in sync - either for intentional (for Firestore) minor version updates or unintentional patch updates that are automatic for source distributions.
We'll talk to the Firestore and gRPC teams and see if we can/should do something different.
Not sure if this is intentional or not, but there have been a train of semver patch releases for 1.65 gRPC semver minor - they are on 1.65.5 now, and there are also new semver minors over there as well (1.66 and 1.67 release series with 1.68 coming soon):
https://github.com/grpc/grpc/tags
I noticed this because the firestore-ios-sdk-frameworks binary distribution of firestore for cocoapods is set to take any
1.65.0version in the Firestore podspec transitive deps list and hard code it to 1.65.1:https://github.com/invertase/firestore-ios-sdk-frameworks/blob/5bf9a6e17f3462d412af478e3b9006c434df5e12/.github/workflows/scripts/extract-versions.sh#L20-L27
That leads me to believe that the firestore-ios-sdk-frameworks will potentially miss out on critical bug fixes over time without continuing manual maintenance
Should this repo mirror the available release tags of gRPC upstream more closely - with some ability to automatically fetch + package + tag new releases, and then downstream the firestore-ios-sdk-frameworks should also allow that dependency to slip in the
~> X.Y.0way that the firestore podspec describes it? (which would leave us on gRPC 1.65.5 currently - what a pod install fetches now when not using firestore-ios-sdk-frameworks binary build)