Release builds can't find XCTFail about combine-schedulers

[stephencelis]

@CraigSiemens The dependency isn't strict, so you should be able to update your application's dependencies to take on the latest version, which doesn't have this problem. We'll look into a forced upgrade in the next version, though.

[CraigSiemens]

Yeah, that's what I needed to do to resolve it. But if the Package.swift was updated to require >= 0.2 then it'd be done automatically and wouldn't need to be manually updated.

[stephencelis]

@CraigSiemens We'll do that with our next release, for sure.

[mRs-]

any news on this, or is there a fork that I can use in the meantime? Can't compile currently my code for the AppStore...

[mRs-]

fixed in #42

[mbrandonw]

We'll merge and tag once tests pass, but for future reference you can update your packages without waiting for us to cut releases by right clicking the package in Xcode and selected "Update package":

This is the preferred way to update because you don't need to wait for us to cut releases for xctest-dynamic-overlay, and then combine-schedulers, and then TCA, on and on...

[mRs-]

The main Problem is the Package.resolved in the xctest-dynamic-overlay Package, it's pinning the version and Xcodes things that this specific version should be checked out. I removed that as well.

I know it's possible to update single packages, but my CI System was very confused about this 🙁

[mbrandonw]

Ok, hopefully this is fixed now! Closing this issue, but do let us know if there are more problems.

[stephencelis]

The main Problem is the Package.resolved in the xctest-dynamic-overlay Package, it's pinning the version and Xcodes things that this specific version should be checked out. I removed that as well.

@mRs- It may not be intuitive, but a package's Package.resolved doesn't have any bearing on how apps that depend on the package resolve their dependencies. In this case, our Package.resolved file only influenced package resolution of if you clone the combine-schedulers package and edit it directly.

From the SwiftPM docs:

Either way, for a package which is a dependency of other packages (e.g., a library package), that package's Package.resolved file will not have any effect on its client packages.

—https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#resolving-versions-packageresolved-file

[mRs-]

Yep I thought so too, but this is not really working for me in the latest Xcode 13 RC. It's always using the "older" version when you check it out with the -resolvedependencies flag on the command line :(