Best practices for evolving Kotlin libraries
summary
Explains concrete JVM compatibility pitfalls (renaming named parameters, adding defaulted params breaks binary) and shows a practical workflow: use the binary compatibility validator Gradle plugin (API dump + API check, CI fails on unintended changes, now supports native), enable explicit API mode for visibility and return-type checks with IntelliJ quick fixes, treat main sources as warnings-as-errors, and use staged deprecation (warning → error → deprecation level hidden) plus opt-in experimental annotations to safely evolve libraries.
AI-written summary · about
chapters (8)
- 0:00Kotlin library evolution intro
- 3:00Why compatibility matters
- 10:53Breaking binary compatibility risks
- 11:13Tracking compatibility with tools
- 17:02Enforcing explicit API mode
- 23:52Deprecation strategies
- 29:11Adding new features
- 34:14Library API lifecycle summary
related talks
42mEvolving your Kotlin API painlessly for clients- 42mEvolving your Kotlin API painlessly for clients
59mHow to Evolve Your Kotlin Library Painlessly for Clients
22mBuilding SDKs - The Kotlin Way
16mHow to get satisfaction from ungrateful work: A journey into updating Kotlin
41m10 Tips to Make Libraries Kotlin-Friendly
23mMetadawhat? Managing compatibility of your Kotlin apps and libraries
39mKotlin, Practically Speaking