@parse-community/ios-osx - I'm at a loss with Carthage, I assume there is a command to run to get Carthage to do it's thing - anything I try just errors with exit code 65. Any hints?

I’ve never looked at LiveQuery, but if it’s similar to the Objective-C SDK, then you probably need to use the rake script to get the Carthage build to work properly as it does some extra things

Update: I take that back, from the Travis file it looks like it doesn’t use rake

Any movement on this PR, as it stands, a demo project with Parse and ParseLiveQuery imported via pods is failing.

Unfortunately not, feel free to assist if you have a good understanding of Carthage.

Awesome, essentially I'm trying to replicate #226 - as you can see I've updated the Cartfile. I'm imagining there is a command to run that will update the .resolved file and update the submodules - it was a week ago now but I think I tried carthage bootstrap and carthage build both of which failed (with exit code 65 I believe).

Unfortunately that's as far as I got (I've never deployed this SDK before!). There is some limited info on the Carthage readme that I was going off.

@TomWFox maybe I’m understanding your problem wrong, but the circle file currently has Carthage building on the nightly workflow instead of a PR. It looks like it built fine a day ago https://app.circleci.com/pipelines/github/parse-community/ParseLiveQuery-iOS-OSX/202/workflows/52ae0a3f-ce2a-4bcc-94ec-976c3cdedbfb/jobs/2014

Are you saying the dependencies aren’t updated? I think if you add it to the PR job at the bottom of the circle file, you can check if it builds correctly with your updates. In the current setup, it looks like it builds from the master branch nightly

Are you saying the dependencies aren’t updated?

That's what it comes down to, in #226 the 'Submodules' in Carthage/Checkouts are updated - I don't know how this should be done.

I think I might understand the problem now. My guess is those submodules need to be updated locally on your computer using something like, carthage update --platform iOS. I believe that will update the folders. If that’s true, I’m guessing 226 committed those files/folders in the PR. I know that’s how the Gemfile.lock updates work.

It doesn’t seem like circle is configured to pull the submodules from the updated cartfile itself

Well I must have done something that worked last week because it turns out the resolved file was updated. I tried carthage update --platform iOS out of interest but this failed with exit code 1 although the last thing in the xcodebuild log was build succeeded 🤷‍♂️

It may well be something to do with my local environment.

It may well be something to do with my local environment.

Same thing happens to me on my local obj-c SDK build. Something isn’t right with my environment so I just rely on the CI for that one.

No luck on the cocoapods deployment, at first the issue was an expired trunk token but I replaced it, re-run the build and it failed again.

So this issue has me in a pickle. My build was failing and I asked in Q #228 and the solution proposed has worked... until today.

The link is gone for the #228 fix and the release is still broke... at least for me.

So, I was wondering a status on this, or if the link from #228 could be re-instated.

This is an awful time for us as we ere in the process of app release and needed to fix a small issue. But now, we can no longer build.

Thanks for any info and all your hard work... you guys are all awesome!

Did you put the pods in the Podfile like you typically would and try "pod update"?

Yes, I call pod update. Below are the contents of my pod file and the error I receive:

  # Pods
	pod 'Bolts-Swift'
	pod 'UBottomSheet'
	pod 'CalendarKit'
	pod 'Cosmos'
	pod 'DateTimePicker'
	pod 'DynamicBlurView'
	pod 'FacebookSDK'
	pod 'GoogleSignIn'
	pod 'MessageKit'
	pod 'Parse'
	pod 'ParseLiveQuery', '2.7.2'
	#pod 'ParseLiveQuery', :git => 'https://github.com/parse-community/ParseLiveQuery-iOS-OSX', :branch => 'release'
	pod 'Parse/FacebookUtils'
	pod 'Parse/UI'
	pod 'PopupDialog'
	pod 'PullUpController'
	pod "Pulsator"
	pod 'SCLAlertView', :git => 'https://github.com/vikmeup/SCLAlertView-Swift.git'
	pod 'SnapKit'
	pod 'Starscream'
	pod 'SwiftyAttributes'
	pod 'SwiftMaskTextfield'
	pod 'Stripe'
	pod 'SVProgressHUD'
	pod 'SZTextView'
end

And here is the error I receive:

MacBook-Pro:<PATH_HERE>$ pod update
Update all pods
Updating local specs repositories
Analyzing dependencies
Pre-downloading: `SCLAlertView` from `https://github.com/vikmeup/SCLAlertView-Swift.git`
[!] CocoaPods could not find compatible versions for pod "ParseLiveQuery":
  In Podfile:
    ParseLiveQuery (= 2.7.2)

None of your spec sources contain a spec satisfying the dependency: `ParseLiveQuery (= 2.7.2)`.

You have either:
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.
MacBook-Pro:<PATH_HERE>$

I hope this helps you resolve the issue.

Can you try to add, "pod 'ParseLiveQuery', :git => 'https://github.com/parse-community/ParseLiveQuery-iOS-OSX, :branch => 'master'" to the Podfile.

Then type pod update. You will have to pull from the main branch if you want the latest. if you want to use the old version of LiveQuery, you should be able to use the last pod that's on Cocoapods with the iOS 1.19.0 SDK

Yes, I switched to the master branch, performed pod update, cleaned my project and rebuilt. Everything worked as expected.

So, question: will I need to change to '2.7.2' when it is released?

Thanks for looking into this

You don’t need to necessarily change, 2.7.2 just isn’t officially on cocoa pods yet, but you are technically using 2.7.2 now because that’s the latest commit to the master branch. If you want to keep using the latest updates even without a version being released, you can leave your pod file the way it is. You can also tie your pod to a specific commit, just in case a change to the master ends up breaking your code.

Awesome!! Thanks for the help!!!

The podspec is still set to 2.7.1. That's perhaps why we can't push a new version to Cocoapods 😃.

🤦

Cocoapods will take the tagged version of 2.7.2 (rather than the one with the updated version numbers) if I push the spec now won't it?

I think you would have to publish manually as the cocoa pod build won't run but maybe we could delete the tag, merge your pr and recreate it...

I've deleted the 2.7.2 tag so I think if we merge your PR it should work.

Maybe it would be cleaner to just go to 2.7.3...

I've deleted the 2.7.2 tag so I think if we merge your PR it should work.

Ahh 😃 Let's do that then.

Maybe it would be cleaner to just go to 2.7.3...

To finish the thought, some people likely have the old 2.7.2 tagged version.

I don't see any harm in retagging a new commit with 2.7.2... is there any?

In this case, probably not. We'll see 😃

It looks like 2.7.2 hasn't been pushed into Cocoapods yet, which is limiting our ability to update both ParseLiveQuery and Parse in our systems (we can't easily use anything in the podfile, as we are shipping a framework, so we need to keep everything in the podspec files).

Can anyone get the new update pushed into Cocoapods for public use?

It's out so hopefully all issues people were facing should be resolved... 🙏

I had to manually publish which I wanted to avoid but I don't have the knowhow/time right now to work out why it fails and clearly no one else does 😢