Evolving your Kotlin API painlessly for clients
summary
Practical checklist: include the binary-compatibility-validator Gradle plugin and commit its baseline; run apiDump / apiCheck tasks so CI fails when JVM signatures change; enable explicit API mode to force public visibilities and return types; use Kotlin’s deprecated levels intentionally — warning → error → hidden — so removals first warn then break then hide while preserving ABI for old consumers; annotate experimental features with requiresOptIn and prefer propagating opt‑in through public APIs.
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
17mKotlin Library API Design and Compatibility Challenges
35mMastering API Visibility in Kotlin
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
38mBuilding libraries for the next 25 years