Read the removals section first
Serguey Asael Shinder2 min readRelease notes are written to be read from the top, and the top is always the good news. Three of this week's releases put the part that will actually cost someone time further down.
Rails 7.2.4 fixes bugs, but the sentence that matters is the one after the version number: it is the last 7.2 release, and security fixes now go only to 8.0 and 8.1. GDB 18.1 leads with non-stop debugging on Windows, while its removals list drops the stabs and mdebug formats, the dbx binary format, Common Trace Format output, old .gdb_index sections and version-1 DWARF package files, and changes the format of saved execution records so older ones no longer load. And Amazon RDS for PostgreSQL now offers post-quantum TLS key exchange - from version 18 onwards, which is a removal in disguise for everyone on an earlier major version.
Why removals are where the risk is
An added feature is optional; nobody's system breaks because they did not use it. A removal is mandatory the moment you upgrade, and it lands on exactly the things nobody looks at: the old trace file kept for an audit, the build artefact with an index generated years ago, the gem that pins a framework version nobody has touched since the last migration. These fail at the worst time, because they are only opened when something else has already gone wrong.
End of support is the same kind of change with a delay. Nothing stops working on the day 7.2 closes. What changes is that the next vulnerability in shared code gets fixed somewhere you are not, and a patch-level upgrade turns into a major-version migration on someone else's schedule.
A habit worth adopting
Read release notes bottom-up. Start with removed, deprecated and changed-format sections, then compatibility and supported-version statements, and only then the new features. For each removal, ask one question: do we have anything, anywhere, in the old format? The answer usually lives outside the codebase - in archives, backups, CI caches and documentation - which is why it has to be asked deliberately.
The second habit is to record end-of-support dates where planning happens, not where dependencies are declared. A version pinned in a lockfile tells you what you run; it does not tell you when that choice stops being safe. A line in the team's planning calendar - "Rails 7.2: no fixes after 24 September 2026" - does.