A modern programming language that makes developers happier.

kotlinlang

Got a question regarding the <https://github.com/material-components/material-components-android-compose-theme-adapter/releases/tag/material-v1.1.17|material-components-android-compose-theme-adapter>. The latest stable release 1.1.17 targets Compose 1.3.0-beta01. This does not follow the same structure that accompanist does, which supports only stable compose releases on stable accompanist release, beta compose on accompanist beta and so on.
So this means that if we bump to this latest, we’re then transitively depending on the beta version of the compose non compiler libraries.
Does this have any implications regarding our running code? From what I understand, if we don’t define some dep explicitly, the transitive dep will take over and gradle will pick the latest version of it. If we do have it defined explicitly I am not sure what it will pick if the transitive is 1.3-beta and ours is 1.2.1.
Is this something I should even be worried about in any way? Some help here would be much appreciated.

In a default setup, it means that you will be transitively depending on Compose 1.3.0-betaX. 

I'm not sure why Accompanist is now chasing the bleeding edge. We did it in the run up to 1.0 as the Compose releases would be binary incompatible a lot of the time. As a 'foundational’ library though, it should probably be sticking to the oldest workable version available.

Aha so by depending on it transitively I also inherit whatever possible changes have happened to it, despite having explicitly declared 1.2.1 as my normal compose dependency, good to know.

And this isn't a problem about accompanist, as that one nicely has a stable and a beta/alpha release which depends on the correct compose version, so that's good (currently latest stable 0.25.1 depends on latest stable compose 1.2.1). But the MDC one doesn't, so that we will then have to hold back from bumping due to this, just to be on the safe side.

Also as a side note, it doesn't give me much confidence that the MDC lib is a standalone lib outside of androidx and even accompanist. Makes me wonder whether I should bite the bullet and simply define my MaterialTheme myself making sure I set each value the same as it is in the XML files and simply keep track of having them in sync myself.

FYI: you can verify what version you're using by running `./gradlew app:androidDependencies`

Thanks a lot for the tip, didn’t know androidDependencies exists, that’s super convenient!
And yes indeed, I can confirm bumping to the latest MDC brings in the beta version of compose. I guess I’ll have to manually make sure we don’t depend on the latest stable mdc dependency to avoid unexpected behaviors.
I really wish that repo could be moved into accompanist too in order to follow the same guarantees that accompanist gives regarding stable-unstable dependencies, hopefully sometime in the future :crossed_fingers:

Sorry about that, I've reverted to stabled Compose 1.2.1 for the upcoming 1.1.18 release (should be out later today). And yes it's somewhere in the middle of my todo list to move the lib to either Accompanist or AndroidX, and merge it with the Accompanist AppCompat theme adapter library in the process. I'd love to hear thoughts on this if y'all have any :slightly_smiling_face:

Awesome to hear Nick, thanks for updating us on this. It sounds to me getting it into accompanist first is imo the right move, if we are to look at the insets example it shows that it was a really good process and what ended up on androidx was a very good result. This library can take the same treatment and that way we can hopefully get the same success story moving a more robust API to androidx later.
Just my thoughts on this :+1: