Rxswift: RxAtomic 4.4.1 versioning breaks RxSwift 4.4.0

[freak4pc]

The public interface for RxAtomic has changed in RxAtomic 4.4.1.

Since RxSwift Podspec takes any version of 4.4 (e.g. https://github.com/ReactiveX/RxSwift/blob/master/RxSwift.podspec#L38), RxSwift 4.4.0 greedily uses RxAtomic 4.4.1, which creates breakage:

Installing RxAtomic (4.4.1)
Installing RxSwift (4.4.0)

The only way to solve this without a change to our repo is to manually specifiy pod 'RxAtomic', '4.4.1', etc. In this specific case I imagine the release for RxAtomic should have been 4.5.0 since it was changing public interface for that source, which would change RxSwift's version as well.

The podspec version of RxAtomic and RxSwift's dependency on it must always be interlocked on new releases. I'm not sure if there's a way to make a Danger rule for it, but it might be a worthy attempt.

I'm also not sure on how to backward-fix this. Can we replace a podspec of an already-published version ?

[kzaher]

Hi @freak4pc ,

I’ve added a set of new methods because I didn’t want to break the backwards compatibility.

After digging through history I’ve noticed that @LucianoPAlmeida added thread sanitizer flag, but that shouldn’t cause breaking changes.

I’ve missed the fact he also changed ‘self’ to ‘_’ in 403cc940d89e4ec2298a91f99b9c13f34a2e923f. Damn it.

I guess it is a mishap. We can’t fix this. Once tags are set, we can’t change them.

Having said that, why don’t you just use 4.4.1?

[freak4pc]

It’s for the Rx book - everything is set for 4.4.0, we’ll have to go back and apply manually.

I guess we could fix it but it would require changing history, e.g., either:

1. Kill the 4.4.1 tag, push a reverting change to go back to 4.4.0, make the fixes and recreate the tag and podspec; or,

2. Same as above but force push (much more risky but if it’s just the last one commit it might not be too bad, YMMV).

We can also just leave as is - this is more of a specific issue in our use case :)

[freak4pc]

Scratch that - just realized there have been way too many changes between these releases. The only solution would actually be some sort of an interactive rebase completely changing the commit history on master, which is too painful for how minimal the issue is here.

I think we’ll close this for now ?

[kzaher]

I guess we could fix it but it would require changing history, e.g., either:

1. Kill the 4.4.1 tag, push a reverting change to go back to 4.4.0, make the fixes and recreate the tag and podspec; or,
2. Same as above but force push (much more risky but if it’s just the last one commit it might not be too bad, YMMV).

Ugh. I guess I've made a mistake by not noticing that small breaking change. My brain was focused on the thread sanitizer part, and I've missed that small part of the line change.

I guess what is done is done. I know how to solve this from technical point of view but I wouldn't want to change git tags and rewrite history. IMHO that would be a huge hammer to solve this inconvenience.

In extreme circumstances I would be fine with rewriting history (accidentally publishing some PII, accidentally publishing some other highly sensitive material) but I wouldn't like to do it for this.

Unless there is some realistic action point, let's close this for now.

[LucianoPAlmeida]

Hey guys @freak4pc @freak4pc :)

After digging through history I’ve noticed that @LucianoPAlmeida added thread sanitizer flag, but that shouldn’t cause breaking changes.

I’ve missed the fact he also changed ‘self’ to ‘_’ in 403cc94. Damn it.

@kzaher But this change shouldn't affect this since the RXAtomic API changed to arbitrary functions on ba930dca0c71679e3e9a87b14f4ce1a4ff61f3d6 and we and up removing this anyway.

IMHO that would be a huge hammer to solve this inconvenience.

Agreed.

One other option could be to introduce a new 4.4.2 for example where we add back a retro-compatible RxAtomic API (assuming that if we have a 4.4.2, RxSwift 4.4.0 will try to fetch that as well since is the latest) and (also knowing that it has data-race issues) together with the new one, so that will work both ways. I don't know if it's is possible to maintain both API's together without conflict and also not 100% sure if it would work (but make sense to me and I don't see why not), and last but not least, maybe it also "would be a huge hammer to solve this inconvenience".
But just dropping the option, maybe it makes sense and can be a reasonable option here ;)