Serguey Asael Shinder: Two sections of a JDK release note decide whether a build breaks
A JDK release note is long and most of it does not apply to you. I read them in the same order every time, and I skip the same things every time.
First: removed and deprecated-for-removal. This is the only section that can break a build that currently works. Everything else is opportunity; this is obligation. If nothing here touches your dependencies, the rest of the note is optional reading.
Second: the behavioural changes that are not flagged as features. Default values, garbage collector tuning, TLS defaults, locale data. These change what your program does without changing what it compiles to, which makes them the ones that surface in production rather than in CI.
Then stop. New language features will still be there next month, and you will read about them properly when you have a use for one. Reading a preview feature you cannot use yet is entertainment, not maintenance.
The practical version: search the note for Removed, then for changed the default, then close it. Ten minutes, and the two things that could cost you a weekend are handled.
Part of the running notes: Upgrades that change behaviour, not just version numbers