-
Notifications
You must be signed in to change notification settings - Fork 429
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
ReactiveSwift 6.5.0 not binary compatible with 6.4.0 #809
Comments
ReactiveSwift does not declare ABI stability as stated in the readme:
|
Hey @dnadoba, that's a fair point, maybe "binary compatible" isn't the best term to use here, it might be better to just say "breaking change". So in this case, there was a small breaking change between minor versions (6.4 to 6.5) that I don't think the team was aware of based on the versioning, pull request, and release notes. Right now, if your project uses Carthage to pre-build its frameworks and has dependencies on both RAC and RAS that get resolved to the latest releases of both, then you'll likely have the issue that the sample project above demonstrates when you use Another way to solve this would be to bump ReactiveCocoa's minimum version for ReactiveSwift to 6.5, but that might just be replacing one semver problem with another. |
Doesn't Carthage automatically rebuild all downstream dependencies when there's a new version of e.g. RAS? |
I can confirm that if you upgrade the version of ReactiveSwift from 6.4 to 6.5, Carthage will rebuild ReactiveCocoa as well. |
The problem is a bit more subtle than that. Assuming our app's Cartfile.resolved matches the latest versions, (RAS 6.5 / RAC 11.1), the build process with Carthage looks more like this: Note that ReactiveCocoa 11.1's local ReactiveSwift dependency is resolved to v6.2 in its Cartfile.resolved + submodule.
This should work fine, because v6.5 is expected to be backwards compatible with v6.2, but there's this subtle incompatiblity introduced from that change that results in a bad memory access. |
If I understand you correctly, ReactiveSwift is built twice after being upgraded? Why would it rebuild ReactiveCocoa when it's still linking against the old framework, you wouldn't need to rebuilt it if you're not linking against the new binary? |
Those steps would be from running That can be reproduced using the sample project, just delete the Carthage directory and run To clarify why it's built twice:
|
Thanks for explaining. Would this be mitigated by using a parameter like Edit: Probably not, disregard my question. |
I've encountered similar problems in the past. The reason is that ReactiveCocoa includes ReactiveSwift as a git submodule instead of relying on the dependency provided by Carthage. The advantage of that approach is that you can use ReactiveCocoa out of the box without having to install Carthage first. But if you are using Carthage, you will frequently run into issues unless you use the exact same version of ReactiveSwift that ReactiveCocoa's submodule points to. :( |
Hello. 👋 Thanks for opening this issue. Due to inactivity, we will soft close the issue. If you feel that it should remain open, please let us know. 😄 |
The 6.5.0 release included a change to
OptionalProtocol
(#805):It's a nice API improvement, but unfortunately it seems to break binary compatibility with the previous release, and can cause problems like ReactiveCocoa/ReactiveCocoa#3717.
Adding protocol inheritance isn't explicitly called out as an unsafe change in the Library Evolution docs, but it is causing a bad access at runtime. Here's a small sample project that will fail to launch because of the issue: ReactiveKVOCrash.zip (frameworks compiled using Xcode 12.2).
This means that the latest releases of ReactiveSwift and ReactiveCocoa aren't compatible with each other:
Following the SemVer guidelines, we should probably revert that change and release a 6.5.1 update.
The text was updated successfully, but these errors were encountered: