Don't depend on unstable AndroidX libs

flowbinding-recyclerview 0.11.1 currently depends on androidx.recyclerview:1.2.0-alpha02.

I think this is a mistake, as it transitively pulls in unstable libs the consumer may not want.

I propose a policy of never depending on unstable AndroidX library versions.

If this is a required use case, separate unstable artifacts could be published.

[ychescale9]

Thanks for calling this out. I agree we should depend on stable versions of AndroidX for version 1.0.0 of the library.

The only reason I’ve been able to get away with using the alpha version of AndroidX dependencies is that we’re technically not API stable either.

In terms of binary compatibility and the effect of depending on non-stable AndroidX libraries:

• AndroidX libraries won’t break backward compatibility without a major version bump (e.g. ViewPager2 which we have a separate artifact for)
• FlowBinding’s artifacts use implementation to depend on the relevant AndroidX dependencies. ~This means consumers of FlowBinding need to explicitly bring in the dependency e.g. androidx.recyclerview in order to use a binding for that widget. Only the one specified explicitly by the consumer will be packaged into the apk.~ This was based on an invalid assumption that user doesn’t have any other library that transitively depends on the AndroidX lib in the classpath which is very wrong.
• We are tracking binary compatibility of our public APIs using the binary-compatibility-validator plugin.

That said, since the bindings we provide don’t use any of those new APIs (maybe except for the material components bindings), there are no reasons to depend on an alpha / beta version of AndroidX.

Will try to address this soon.

[ychescale9]

I don’t really want to rely on documentation to warn users about potential crashes 😅 . All the different versions of AndroidX and their transitive dependencies are already quite brutal for an average user.

I think we should probably just follow how AndroidX handles this. A stable release will just depends on stable release of transitive dependencies. User doesn’t need to know that what they’ve explicitly declared e.g. 1.0.0 has been overridden by a library’s transitive dependency 1.1.0, as they are both stable.

I’m not sure how to go about managing a separate non-stable release train 😂 . The AndroidX repo has a lot of custom plugins / tooling / process to support that which I don’t have.

I’ll look around a bit to see how other libraries handle this.