Prepare for 6.31.1

[paulb777]

Targeting publishing Monday morning to provide a fix for a Xcode race condition build failure. (#6341)

[mikehardy]

Hey @paulb777 / @ryanwilson - a release engineering note, somehow the 6.31.1 release wasn't complete in the way previous releases have been? Basis for that assertion is that the "Latest Release" on github is still showing as 6.31.0, and there's no binary zip connected with CocoaPods-6.31.1 tag. This comes up (for me, and likely others) because the pre-compiled firestore-ios-sdk-frameworks keys off the fresh release existing and then pulls from the zips in order to pre-compile firestore and accelerate all the FlutterFire and react-native-firebase users's builds

• What previous release looks like: https://github.com/firebase/firebase-ios-sdk/releases?after=DataTransport-7.3.0
• What current looks like: https://github.com/firebase/firebase-ios-sdk/releases
• Where we fail to find release: https://github.com/invertase/firestore-ios-sdk-frameworks/blob/640fa0a865e5338b5135a2f785b29c6030cb0f44/.github/workflows/scripts/process-latest-version.sh#L79
• Why this is even a thing :-) - https://github.com/invertase/firestore-ios-sdk-frameworks#before--after

[paulb777]

@mikehardy sorry about the confusion.

See https://firebase.google.com/support/release-notes/ios

We released 6.31.1 only for CocoaPods since we've had numerous reports of not finding the Firebase module during builds that we were never able to reproduce but turned out to be a change in 6.28.0 exposing an Xcode build race condition. Details in #6341.

Since we had no reports for other distribution mechanisms, we skipped the release engineering associated with them in favor of deferring to 6.32.0.

I would suggest that you ignore any releases that don't regenerate a zip distribution, but happy to discuss other processes.

And thanks for providing such a nice speed-up for Firestore users!

[mikehardy]

Well that was all @Salakar to give credit where it is due, you're becoming more familiar with me because I'm more like the Chief Plate Spinner just trying to keep everything working and then diagnosing when it's not :-). The script I referenced will just automatically fetch 6.32.0 whenever it happens, but we can't control if people attempt to use 6.31.1 - it will just fail for them if they try. Is that a problem? I don't know

But I can add to the script some output indicating why it is not working (so this exchange doesn't happen again) and I can add some documentation to the repository so people can understand why the pre-compiled framework might not be available and just to wait a version if so. That is likely good enough (it is for me)

[paulb777]

Sounds good!

If not, there might be an approach around tagging, versioning, and publishing the FirebaseFirestore binary podspec.

[mikehardy]

If there was anything related to that one broken out at a sub-spec level (since our framework pre-compiler is already looking at the subspec from cocoapods IIRC) we could probably alter it to hook to that. If you all think on that and come up with anything, tag me or Mike D (salakar) in and we can collaborate, sure