Backwards Incompatible Tales
summary
Argues that backwards-compatibility breaks are inevitable but manageable, with concrete examples (Boeing 737 MAX, Doctrine’s added repository count causing eight issues) and a real tool: backwards compatibility check that finds removed classes, changed signatures and non‑contravariant type swaps. Distinguishes type vs behavioral breaks, shows tests catch the latter, recommends semantic versioning and deprecation windows, and highlights tradeoffs for security patches and maintenance of perceived stability across libraries and releases.
AI-written summary · about
chapters (13)
- 0:00Start
- 2:58CHANGE IN REQUIREMENTS
- 3:27SYSTEM CHANGES
- 7:25BC BREAKS ARE NORMAL
- 9:26CHANGES IN TYPES
- 23:50DOES TYPE X FIT INTO TYPE Y?
- 24:59MAKE THINGS "FINAL"
- 25:11MAKE THINGS "@INTERNAL"
- 27:08CHANGES IN BEHAVIOUR
- 32:05TEST CHANGES?
- 33:05THIS IS WHERE TESTS PAY OFF THE MOST!
- 36:17BROKEN SYSTEM BETTER THAN COMPROMISED SYSTEM
- 38:05CONSIDER DEPRECATING THINGS FIRST
related talks
30mBreaking backwards compatibility: The easy way!
30mBreaking changes in Design system
28mHow to stop breaking other people's things
44mBackporting is so 1993
01h 01mGuide to Destroying Codebases the Demise of Clever Code
41mCreating A Better Developer Experience By Avoiding Legacy Code
35mRedundancy Driven Development - Navigating disruptive codebase changes.
47mKeeping up to date in a bespoke software development world