How to Avoid Breaking Changes in your Go Modules
summary
Prometheus is used as a concrete example (35,000 imports) and a go.mod audit finds 181 dependencies with many still at 0.x while only ~11% are v2+, exposing real versioning pain. Advice: define API boundaries with internal packages to stop accidental exports, split independent code into separate modules, and use interface upgrades (new small capability interfaces like Flusher/Exemplar) or the rule accept interfaces, return structs to add features without breaking consumers.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:03Prometheus as Go module
- 3:11Semantic versioning
- 6:43Go modules vs versioning
- 8:32Costs of major bumps
- 10:40Staying on 0.y.z
- 13:08Dependency trends in Go
- 14:54Podcast plug
- 15:38API surface definition
- 17:45Module granularity
- 19:10Pragmatism in breaking changes
- 21:18Interface upgrades
- 24:05Accept interfaces return structs
- 26:13Closing remarks
related talks
38mUsing Go Modules in everyday life
36mAvoiding Breaking Changes in Your Project: Lessons From the OpenTelemetry Collector
26mEvolving Your API
24m"Finding Dependable Go Packages"
33mTransition to Go 2
46mRediscovering Go
19mHow to Future-proof your Go API
33mHow to Safely and Efficiently Build your App with Modules