Evolving your Kotlin API painlessly for clients
summary
Concrete rules and tools for keeping a Kotlin library stable: use the binary compatibility validator Gradle plugin to generate an API dump and run API check so the build fails on accidental signature changes, enable explicit API mode and warnings-as-errors for production sources, follow a deprecation lifecycle (warning → error → hidden) before removal, prefer opt-in or propagation for experimental APIs, and supplement with integration tests or JApiCmp/jar diffs; Kotlin teams report this workflow prevents painful transitive breakages.
AI-written summary · about
chapters (9)
- 0:00Introduction
- 3:20Compatibility in Kotlin libraries
- 11:36Compatibility types and risks
- 13:21Binary compatibility with validator
- 17:41Explicit API mode for safety
- 24:41Deprecating API elements safely
- 31:10Experimental versus stable APIs
- 39:47API lifecycle and deprecation
- 41:33Resources and closing
related talks
42mEvolving your Kotlin API painlessly for clients
36mBest practices for evolving Kotlin libraries
59mHow to Evolve Your Kotlin Library Painlessly for Clients
17mKotlin Library API Design and Compatibility Challenges
35mMastering API Visibility in Kotlin
22mBuilding SDKs - The Kotlin Way
48mBuild Your Java/Kotlin Library
38mKotlin for API Tests