ApiVer – a versioning policy for libraries
summary
A practical versioning policy called ApiVer maps each released API version to a tiny adapter layer so internal code can be freely refactored without forcing users to change imports. Each public symbol has one line per public member in the adapter, adapters form a chain from older to top version, and packages only ship the top implementation plus lightweight wrappers so size impact is minimal. It handles renames and added arguments, but requires a flat namespace and care defining the public surface; some wrappers may be hard to write.
AI-written summary · about
chapters (6)
- 0:00Start
- 8:44Usage example
- 11:01Implementation
- 12:29Rename
- 13:24Add mandatory argument
- 15:22Various issues
related talks
01h 18mAPI design: Lessons Learned
21mNew Generation of APIs with API Star
10mPy-Versionweb - Making Version Control Easier
40mLatest advances in the Google APIs platform
18mNo more sassy SaaS integrations
42mArrested Development: surviving the awkward adolescence of a microservices-based application
07mVerified fakes with OpenAPI
27mAPI development for data analysts/scientists with FastApi