Breaking backwards compatibility: The easy way!
summary
Advocates concrete rules: use semantic versioning (SemVer) and bump major for breaking changes, cap dependency major versions so upgrades dont pull v2 unexpectedly, mark APIs with stability attributes (stable/experimental), deprecate with advance warnings rather than removal, run cross‑version integration tests (an integration gate testing releases against real downstream stacks), prefer private by default, keep APIs consistent and follow design‑by‑contract, and publish alpha/beta releases to gather feedback before a stable cut.
AI-written summary · about
chapters (18)
- 0:00Intro
- 1:48Disclaimers
- 3:34What is backwards compatibility
- 5:18What to do with your software
- 7:24Assumption
- 8:24Keep everything public
- 9:09Keep users in the dark
- 9:55Start talking seriously
- 11:27Why is this important
- 12:50Saving time
- 14:04Versions
- 16:43Communication
- 19:01Consistency
- 20:03Design by contract
- 21:51Privacy rules
- 23:15Stability attributes
- 25:39Integration tests
- 27:18QA
related talks
44mBackwards Incompatible Tales
28mHow to stop breaking other people's things
30mBreaking changes in Design system
35mUpgrading Legacy Projects: Lessons Learned
24mWhy We’re Afraid of Change
26mHow to Break an API: How Community Values Influence Practices
25mHow to Approach Retroactive API Versioning
47mHow To Build Future Proofed Applications