Building libraries for the next 25 years
summary
Practical advice and concrete tradeoffs: a real-world Apollo Kotlin client shows why names should be memorable, why supporting Java vs JavaScript forces duplicate APIs, and why Builders vs data classes matters for evolving defaults and null/optional semantics. Publishing notes name Maven Central and pain points with multiple publish flows and Gradle plugins, and the recommended tooling includes binary-compatibility-validator to track ABI, careful deprecation with replaceWith, and treating alphas as usable for real feedback while avoiding breaking changes.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 3:59Naming for library identity
- 6:03API design Java vs JavaScript
- 9:33Kotlin features for libraries
- 13:05Extension functions and Java interop
- 15:56Error handling and type safety
- 19:29Documentation and publishing
- 25:31Breaking changes and versioning
- 31:10API evolution and deprecation
- 34:20Versioning schemes and pre-releases
- 36:28Key takeaways
related talks
31mTips for Library Development (from a Startup Developer)
29mLessons from a Librarian
43mLibrary Developer Confidential
41mBrick by Brick: Building Open Source libraries
42mEvolving your Kotlin API painlessly for clients
47mThe definitive guide to Android library development
37mAndroid Librarian's Guide: Building Robust Libraries a…
01h 01mGuide to Destroying Codebases the Demise of Clever Code
