Releasing Calendar-Versioned Software

on YouTube ↗32m

" summary

Advocates of calendar-versioned releases argue for time-based, frequent rollouts instead of semver guarantees, and show how Twisted makes it work: automated testing, CI, news fragments to collect changelog items, version-compare utilities, coverage aggregation and micro/macro benchmarks. The project keeps trunk releasable, runs about 5 releases/year, enforces one-year deprecation (or two releases) and treats security fixes as exceptions. Result: large Python codebases (Twisted ported 40,000+ lines to Python 3) ship smaller, safer updates with fewer surprise breakages.

AI-written summary · about

" chapters (38)

1. 0:00Intro
2. 1:33Consistency in your software's characteristics
3. 2:11Upgrading to Version Y is explicit, repeatable
4. 2:26Feature releases Bugfix releases Repackagings
5. 2:53SemVer "Semantic versioning"
6. 3:18A new version of Java is available! Java 8 Update 101 build 13 is now available
7. 4:45Fits well with planning, roadmaps, "top-down"
8. 5:38Easy for developers to understand and use to communicate intent
9. 5:57Why SemVer does not fit reality
10. 6:18No such thing as a "safe release"
11. 6:37Doesn't scale well to complex software (frameworks, languages, operating systems)
12. 7:32"It's okay, we can update the major version number" hurts your users
13. 8:06"Agile" developed software does not fit a "top down" model
14. 10:43Reduce the friction for a user to upgrade constantly
15. 12:59Realities of Software
16. 13:32Regressions will happen
17. 14:23Effective calver requires you adopt better processes
18. 14:42Implementing Calver
19. 15:21Operating systems, enterprise software
20. 15:46Software that talks to external services, software with security implications, libraries/frameworks
21. 17:19Constantly changing software needs to have different QA processes
22. 18:11Issue release candidates and encourage users to run their tests against it
23. 18:50Q: What is a regression? A: When user's software stops working through no fault of their own.
24. 19:16Python import locations Argument names + types Return value types Behaviour
25. 19:42Have A Clear Public API
26. 19:58Abstract interfaces over concrete implementations
27. 20:37Test ONLY using your public API
28. 20:50Mock-based testing means you may hide bugs in the underlying layers!
29. 21:12Re-Export Functionality
30. 21:27Write private modules, re-export into a public one
31. 21:51Can't accidentally export implementation details
32. 22:18Track Your Performance
33. 22:45Microbenchmarks (Black Box)
34. 23:46Implement Code Review
35. 24:20What Aren't Regressions
36. 25:01Safely Making Breaking Changes
37. 27:43tl;dr: Six Steps To Calver
38. 28:15Don't break the user's software!

" related talks

• 43mDownstream Zephyr RTOS Release Management - Keeping up With Upstream PaceParthiban N · Open Source Summit India 2026
• 30mPutting the Semantics into Semantic VersioningPatrick Lam, Jens Dietrich, David J. Pearce · SPLASH 2022
• 41mFrequent Releases & Major ChangesMindaugas Mozūras · DevOps Pro Vilnius 2016
• 44mRelease Early, Often, StableAleksey Kupriyanenko · JavaScript fwdays'20 online conference
• 08mIGNITE: Did Anyone Say SemVer?Philipp Krenn · stackconf 2022
• 10mLightning Talk: Policy as [Versioned] Code - You're Doing It Wrong.Chris Nesbitt-Smith · GitOpsCon North America 2022
• 34mPolicy As [Versioned] CodeChris Nesbitt-Smith · Critical Software Summit @ Open Source Summit Europe 2022
• 27mDevOps Patterns and Antipatterns for Continuous Software UpdatesBaruch Sadogursky · DevOpsCon Munich 2019