Serguey Asael Shinder: The riskiest line in an upgrade is a changed default
The Quarkus team has published an "almanac" that compares any two releases by configuration properties, managed dependencies, extensions and the public API of every class in its jars. (https://quarkus.io/almanac/) What caught my attention is that it lists config properties whose default value, type or phase changed as a category of its own, next to the ones that were added or removed.
That is the right instinct, because upgrade failures come in two kinds and only one of them is loud.
A removed method or class breaks compilation. It is annoying, but it is found in the first five minutes, by the build, before anything ships. A removed config property is nearly as good if the framework fails on unknown keys.
A changed default is different. Your configuration file is identical before and after. Nothing references the property, so nothing fails. The tests pass, because tests rarely assert on a setting nobody thought about. And then a timeout is shorter, a pool is smaller, a schema setting behaves differently, or a dependency managed by the platform BOM moves a patch version while the core BOM does not — the almanac's own example is 68 Jackson artifacts going from 2.21.6 to 2.21.7 in one and not the other.
Three habits have saved me here. Pin the settings that matter for production explicitly, even when they equal today's default, so that a change in the default cannot reach you silently. Read the "changed" section of an upgrade before the "removed" one, because the compiler will tell you about removals anyway. And diff the resolved dependency tree, not just the version you bumped, since the platform BOM decides more of it than the one line you edited.
Release notes are written by people summarising what they think matters. A diff of the published artifacts is what actually changed. When a tool gives you the second, use it before you read the first.