isn't 3.5.0 async a breaking API change?

[mr-git]

@djspiewak, please help us to understand, why async changes didn't lead to major version bump?

If I understood correctly, now we have to be very careful with any library upgrade as our application might break in case when one brings CE 3.5.x in scope while other library uses async. Is that correct assumption?

[djspiewak]

This is an excellent question. The tldr is that, while this is a pretty significant change in semantics, it was (in our judgment) not a thing that would be a danger to 99.9% of call sites. When we made the change, only one call site (outside of laws) in all of Cats Effect had to be changed, and IIRC none in Fs2 (Arman would remember for sure). This was the evidence that I found convincing that most users just wouldn't see this problem in a meaningful way.

---

Longer answer…

This kind of goes to the heart of what "compatibility" really means. What are we promising when we don't change a major version component? What are we promising when we don't change a minor component? Obviously binary backwards (and forwards for minor) compatibility is where we start, but what else are we promising? Clearly we aren't promising to change absolutely nothing! For example, if there's a bug somewhere that causes IO to behave in a specific user-visible way that is wrong, we'll fix that, and we'll probably fix it in a patch version. That's absolutely "semantic breakage" though, since maybe someone has code that's relying on that bug, but we don't promise not to fix bugs.

In my view, because we make minor releases less frequently and major releases almost never, we are justified in putting larger breakage like this into a minor release. To be clear, following the letter of the law, we actually could have put it into a patch release! We didn't do that though, because in the Cats ecosystem, minor releases tend to be a bit larger. We break source compatibility relatively frequently in minor releases, for example, and that is also something which is a lot more likely to randomly break your build when an upstream dependency updates to the latest version. We're aware that this is a pain point for users, but we have to balance this with the need to continue to evolve the library and the ecosystem and the benefits users reap from those changes.

There is definitely a limit to this type of reasoning though. For example, we're discussing a similar question for 3.6 on #3575 as we speak! At some point though, we have to make a judgment call, and in our judgment this change was potentially disruptive but likely to not be as disruptive as other changes that we've already deemed acceptable (such as the Dispatcher changes in 3.4), based on the surprisingly minimal impact it had when we canaried it on the Typelevel libraries.

[armanbilge]

IIRC none in Fs2 (Arman would remember for sure)

For the record, FS2 did need changes. Specifically the async usage in Socket and IIRC in the JS implementations. http4s Ember didn't however, because it builds cleanly on FS2. blaze and http4s-dom did need changes, because they were directly interopping with Future and js.Promise.

[mr-git]

thank you for clarification!