Rxswift: Figure out how to add tests for breaking the ABI backwards compatibility.

[kzaher]

Somebody knows how can we do this?

[LucianoPAlmeida]

@kzaher I don't know exactly how to do it, but looking to the apparently way the swift tests the stability of the ABI/API of the swift standard library. Seems like a way to do it after swift 5.1 (that have module stability) to compare the swiftinterface files for the module. Before the module stability they seems to dump the module interface to a Json format and compare them. I'm not 100% sure about all this, I just got these ideas looking here, but check the way they do it for the stdlib can be a way to check if an similar approach can be applicable here.

[kzaher]

@freak4pc

A bit confused on why, since closed source libraries are also versioned (usually) and possibly locked to a specific API version.

I guess I can see these cases. There could potentially be more:

• If we want to distribute binaries in RxSwiftCommunity for example and we don't keep RxSwift ABI stable then the released binaries will break for using different versions.
• If somebody makes a closed source binary which is depending on RxSwift and wants to redistribute it. The consumer of the closed source binary will make their own build of RxSwift so without ABI stability that could break.

It's hard for me to say how much effort would this take and how many users are there, but I would rather we make a conscious decision do we want this library to be semantically ABI stable or not. I would probably say yes, but if that takes a lot of work and we can't automate it I wouldn't be in favour of making it ABI stable.

We can probably just check what other libraries are doing and do the same.

[kzaher]

@LucianoPAlmeida Thanks, I would need to take a look.

[LucianoPAlmeida]

• If somebody makes a closed source binary which is depending on RxSwift and wants to redistribute it. The consumer of the closed source binary will make their own build of RxSwift so without ABI stability that could break.

One case related to that may be a client that import two closed binary libraries A and B that depends on different versions of RxSwift. So if without ABI to guarantee backward compatibility, that client might not be able to build it because that one that depends on the old version might not be able to link against the Rx binary if it has changed the ABI.

Even that seems very specific and maybe not many people do that, I think is a valid case

[LucianoPAlmeida]

@kzaher @freak4pc
Found two files that maybe relevant to this discussion.
One is the Library Evolution
And the other is the swift-api-digester. It is the implementation file, but it has an overview on the tool.
Just adding the references here to future discussions.

[kzaher]

// swift-api-digester is a test utility to detect source-breaking API changes

@LucianoPAlmeida
I think that's what we need :)

[LucianoPAlmeida]

@kzaher Yeah, but it has no much information about the tool itself or how to use it :((
As far as I could tell, it's tied to the swift project test suite and I'm not sure if is possible to use for code outside the swift project. I was thinking of maybe open a question on the forums?

[keith]

I've submitted a PR to get us closer to supporting swiftinterface https://github.com/ReactiveX/RxSwift/pull/2103

[freak4pc]

I'm closing every issue older than 6 months. If this is still an issue for you, please comment and I can reopen :) Thanks !

In essence, I'm not sure ABI backwards compatibility is as interesting as API backwards compatibility, but if someone is very passionate about this, I'm happy to reopen this discussion.