With Ruby shipping a new minor version every year, how would you set an upgrade cadence and policy for dozens of Ruby services?

## The rhythm you are planning around Ruby's release line is regular. A **minor** release (3.3, 3.4, 4.0) ships **once a year**; Ruby's own headers describe the minor number as changing annually, and 4.0 is simply that year's release, not a rewrite. Between minors, **teeny** releases (4.0.1 ... 4.0.7) carry bug and security fixes. Each branch is maintained for a limited period, then receives security fixes only, then reaches end of life; the exact dates are published by the Ruby core team and should be checked, not assumed. For one service, that makes an upgrade a yearly chore. For dozens of services, it is a **policy question**: how far behind may a service fall, who pays for the upgrade, and what signal says it is safe? ## Options and their trade-offs | Policy | Upside | Downside | |---|---|---| | Track latest within a window | small yearly changes; newest performance work | steady engineering cost every year | | Stay one minor behind (N-1) | gems have caught up; fewer surprises | still yearly work, slightly older features | | Stay on the oldest maintained branch | least frequent work | every upgrade spans several releases and races a deadline | | Upgrade only when forced | no planned work | big-bang jumps, security exposure, lost expertise | Most mature teams land between the first two. The last two concentrate risk: a jump across several releases stacks removals, library moves and format changes into one change, usually under the pressure of an end-of-life date. ## A policy that works in practice 1. **Continuous early signal.** A shared CI job runs every service's suite on the newest Ruby, and on previews once they appear, without blocking merges. It turns "what will break" into a list months ahead. 2. **Deprecations fail the build.** Services run tests with `-W:deprecated` and a `Warning.warn` extension that raises, so removals are fixed while they are still warnings. 3. **An adoption window.** For example: every service moves to a new minor within a fixed number of months of its release, typically after the first teeny release so the gem ecosystem has caught up, and in any case well before the previous branch leaves security maintenance. 4. **Paved road.** One platform team owns base images, the supported-versions list, the build of native extensions in CI, and a running list of known breaks per release, such as which libraries moved to bundled gems. 5. **Visibility.** Each service reports its `RUBY_VERSION` at boot or in its build metadata, so a dashboard shows who is behind without asking. ## Judgement calls a lead owns - **Exceptions.** A service with a hard dependency that has not caught up may stay behind, but with an owner, a reason and a date, not indefinitely. - **Order.** Upgrade low-risk internal services first to harvest fixes, then the critical ones, like payroll, with the playbook already proven. - **Budget.** A yearly upgrade is cheaper per service when it is routine; treating it as a project every few years is what makes it expensive. - **Experiments.** Features marked experimental, such as Ractor or ZJIT in 4.0, stay out of production policy until the release notes drop the label. ## Measuring whether the policy works - **Version spread:** how many minors the fleet spans today. A healthy fleet usually spans two; four is a warning sign. - **Lag:** median time from a release to a service's production adoption. - **Upgrade size:** the number of code changes per upgrade. Small, routine upgrades mean the early-signal CI job and deprecation rule are doing their job. - **Exceptions:** count and age of services held back, each with an owner and a review date. ## What interviewers listen for A principal answer names the yearly cadence and maintenance windows, chooses a policy with explicit trade-offs, and backs it with mechanisms: early CI, deprecations as errors, a window with a deadline, shared paving and visibility.