Evolving Your API
summary
Explains concrete techniques to evolve an API while keeping old code: keep the old API and reduce maintenance cost with deprecation comments, a new major import path (V2), or automated rewrites via the go:fix directive that inlines/ioutil→io uses safely. Recommends future‑proofing with internal packages, unexported interface methods, and three option patterns (exported fields, option structs, functional/variadic options). Shows real cases: io/ioutil migration, Begin/BeginTx, ResponseWriter pusher interface, env‑gated old code, build tags and go experiment for long trials, and concrete counts like 4 net/http internal packages vs 58 in crypto.
AI-written summary · about
chapters (10)
- 0:00API evolution challenges
- 1:46Breaking changes harm trust
- 4:15Future-proofing APIs
- 9:57Case study: wrapping external specs
- 12:06Breaking changes at v0+
- 15:35Safe ways to add functionality without breaking
- 18:47Deprecation strategies
- 19:09Go 1.26 inlining tool
- 21:17Safe user experiments
- 25:50API evolution summary
related talks
42mEvolving Your HTTP APIs, a Step-by-Step Approach
46mEvolving Your HTTP APIs: A Multi-Step Approach
35mDeveloping a Go API client: the do's and don'ts
19mHow to Future-proof your Go API
41mEvolving your APIs, a Step by Step Approach
27mHow to Avoid Breaking Changes in your Go Modules
35mEvolving your APIs, a step-by-step approach
30mEvolving your APIs, a step-by-step approach