The Cutting Edge Of Versioning
summary
Semantic Versioning is ambiguous about what counts as a breaking change, and the talk gives concrete answers: Elm compiler checks actually run the old and new code to auto-classify patch/minor/major, cargo sver checks exists for Rust but grapples with generics and lifetimes, TypeScript treats many changes as breaking, and Unison content-addressed names make upgrades nonbreaking by design. Research on "deep semantic versioning" bakes versions into types. Recommendation: pick an explicit policy, use or build checkers, offer codemods, and keep upgrades low‑coupling.
AI-written summary · about
chapters (18)
- 0:00Versioning strategies
- 1:27What versioning is
- 2:51Semantic Versioning
- 4:59Semantic Versioning challenges
- 9:56Hyrum's Law
- 13:11Versioning as contract
- 17:30Versioning seriously
- 20:20Breaking changes with RFC 199
- 21:47Testing versioning dynamics
- 24:15Elm and Rust's SemVer
- 27:48Type system version checks
- 30:42Unison's content addressing
- 33:12Versions in type systems
- 36:22Advice for developers
- 37:45Guidance for library and framework authors
- 42:59Advice for designers
- 44:46Summary
- 45:29Q&A
related talks
30mBreaking changes in Design system
48mUsing Semantic Types to Squash Bugs
27mHow Codemods Turned a Nightmare into a 3-Minute Migration
58mApplied Modern C++: The problem of messages versioning in API
01h 01mGrowing Pains: Lessons from seeing C++ codebases mature
27mNext-Generation Programming: Rust & Elm
28mConvergent Evolution
25mDefault to Consistent