Does anyone know what the binary compatibility is ...

# compose

[mattinger]

Does anyone know what the binary compatibility is between compose 1.3.x and 1.4.x? ie, what are the things that will break if something is compiled against 1.3.x and runs against 1.4.x? We found a few small things when we went from 1.1 to 1.2, so i would assume there could be something bumping again.

[jw]

What libraries are you referring to. The runtime?

[mattinger]

@jw Yes, the runtime. We’re a multi repo project, with various libraries compiled on their own, and then stitched together in the host application. We’re moving more towards a mono repo, but that’s slow goings.

[mattinger]

So I’m curious what will happen if i just upgrade the host app to compose 1.4.0 if i will get things like NoSuchMethodError and the like.

[jw]

That's a pretty epic failing of the AndroidX tooling. Hopefully there was a bug tracking the binary breakage and whatever error in how it was contributed successfully was corrected.

[mattinger]

Yeah, the previous issue was 1.1 to 1.2, and it occurred through an inline function. Most likely something marked experimental (which we’re in general discouraging outside of our direct design system toolkit, which we’ll update alongside the host app for 1.4.x

[mattinger]

So while the errors was likely on our part (using the experimental stuff), i would hope that there’d be some release notes around what might break.

[jw]

You could diff the API files, I suppose

[jw]

But in general reliance on such APIs will inevitably lead to breakage across compiled libraries

[mattinger]

Or just do it and hope the automated tests catch most of it.

[jw]

Yeah.

[mattinger]

I agree about experimental apis, and like i said, we’re trying to stop people from using them anywhere but the one toolkit library where our design system is implemented so that it can easily be updated with new versions of compose.

[jw]

The other thing you can do is use strict dependencies such that you enforce each library to be updated before you can update the app (or whatever the fan-in repo is)

[mattinger]

Hopefully more of the accompanist stuff will end up in compose. HorizontalPager finally made it. I’m hoping system ui controller and navigation animation will make it soon.

[jw]

https://docs.gradle.org/current/userguide/resolution_strategy_tuning.html#fail-version-conflict

[mattinger]

Also, how are you doing. You’re still at cashapp right? I saw what happened with the founder and it’s absolutely horrible.

[jw]

I am. And yes it was very surreal and unexpected. Bob was the one who approved Kotlin's use way back in 2014 or whenever when it was initially proposed.

[mattinger]

Thanks. We have a lot of teams, so getting everyone to upgrade is always rough. We’re working on integrating renovate so that these sort of things can be semi-automated until we get more stuff in the mono repo

[mattinger]

There’s definitely breaking changes though in 1.4.

1. It’s now a compiler error to call launch outside of a side effect (this is a good thing mind you)
2. The animateTo function for bottom sheets is now internal, and it’s signature changed. It’s replaced by show/hide and expand/collapse

[mattinger]

The second one is still technically an experimental api even in 1.4, so i get that it wasn’t forcing a version bump

[jw]

1 is only source incompatible as they have no way of breaking existing code, only preventing new calls (presumably with a lint check)