Does anyone know the rationale behind with compose...

# compose-android

[mattinger]

Does anyone know the rationale behind with compose.material2 is following the version of compose that it goes with, whereas compose.material3 seems to not do that? We’re looking at maybe using the material3 version of bottom sheets, since they’re quite a bit cleaner and have some useful things (like built in drag handle concepts). But the rest of our controls are material2. What i don’t want to end up with is a situation where we can’t upgrade compose itself because material2 and material3 are based on different versions of compose.

[Stylianos Gakis]

Use the BOM

[Albert Chang]

Because M3 was released over one year after the release of other compose libraries. Btw you shouldn't assume other libraries will always have the same version. Read this.

[mattinger]

I understand the versioning is semi-independent. I had thought though that it was going to be the patch version level what would vary between libraries, keeping the major and minor versions tied to the version of compose. Otherwise, you just get crazy version soup going on.

Also, we use a shared version catalogs for our external dependencies (since we’re poly repo), and boms don’t exactly play nicely with that.

Yes, you could put the bom as an artifact, but from what i gather, you can’t have an artifact in a version catalog with a version number, which means you have to constantly repeat yourself by putting the full artifact coordinates (minus the version) everywhere you use them.

I’m open to suggestion as to how to effectively use the two together.

[Albert Chang]

Then just use the versions in the BOM listed here.

[Stylianos Gakis]

which means you have to constantly repeat yourself by putting the full artifact coordinates

What? How is this any different from not using the bom?

[mattinger]

@Stylianos Gakis if you use a published version catalog and import it via your settings.gradle.kts, you get typesafe symbols that you can import:

implementation(compposeLibs.androidxComposeUi.ui)

Yes, i know there’s a settings plugin that can import a BOM a version catalog, and that’s likely my path forward. If i just use the BOM as a platform, then i’m just dropping literal strings everywhere because version catalogs cannot have libraries that don’t have a version attached to them.

[Stylianos Gakis]

Unless I am somehow completely misunderstanding you, what you are saying is not true https://github.com/HedvigInsurance/android/blob/881d45524376db00e6b59ce0475eef807ebd216c/gradle/libs.versions.toml#L116-L132
And we apply the bom https://github.com/HedvigInsurance/android/blob/f86a2d6ab7e6126e1fd3d1bb01b16a2c03[…]convention/src/main/kotlin/com/hedvig/android/AndroidCompose.kt in the convention plugin which is applied to all modules, and no hardcoding of strings needed