Rails Framework Defaults: Defusing the Time Bomb in Your Upgraded App
summary
Upgrading Rails 5 → 7 at Donut reveals that the app still breaks unless config.load_defaults = 6.0 and each entry in new_framework_defaults.rb is audited and opt‑ed into one by one. The plan uses tests, git blame, reading PRs, occasional cookie rotator scripts and feature flags to toggle risky changes. Going fast by deleting the overrides commonly produces runtime errors; the slow incremental enablement plus monitoring and rollbacks proves reliable and avoids the “time bomb” of frozen, insecure, or incompatible defaults.
AI-written summary · about
chapters (9)
- 0:00Rails framework defaults
- 3:35What are Rails defaults
- 7:59Why defaults change
- 10:45How defaults files work
- 15:01Risks of ignoring defaults
- 17:06Preparing for upgrade
- 20:18Fast vs slow upgrade
- 23:07Improving docs on changes
- 24:54Next steps for upgrade
related talks
31mRails' Insecure Defaults
28mUpgrading Rails: The Non-Technical Parts
40mRails 5.1: Awesome Features and Breaking Changes
32mZero downtime Rails upgrades
35mChanging the wheels on the bus at 80 mph: Upgrading to Rails 3
35mTen years of Rails upgrades
33mUpgrading a big application to Rails 5
29mUpgrading Rails at Scale