Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for 6.31.1 #6368

Merged
merged 2 commits into from
Aug 31, 2020
Merged

Prepare for 6.31.1 #6368

merged 2 commits into from
Aug 31, 2020

Conversation

paulb777
Copy link
Member

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

* Restore Firebase.h now that SPM supports same public header path as CocoaPods
@paulb777 paulb777 merged commit d2482a5 into release-6.31.0 Aug 31, 2020
@paulb777 paulb777 deleted the pb-6.31.1-prep branch August 31, 2020 14:21
@mikehardy
Copy link
Contributor

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

@paulb777
Copy link
Member Author

paulb777 commented Sep 1, 2020

@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
Copy link
Contributor

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
Copy link
Member Author

paulb777 commented Sep 1, 2020

Sounds good!

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

@mikehardy
Copy link
Contributor

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

@firebase firebase locked and limited conversation to collaborators Oct 1, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants