What is the Upgrade Guard and when should I use it?

[ddsha441981]

We are planning a Spring Boot 3.3 to 4.0 upgrade. I read that autoconfigurations can silently stop matching. How does WireDoctor catch this?

[ddsha441981]

The Upgrade Guard exists precisely for this scenario. The failure mode it catches: you bump Boot, an autoconfiguration quietly stops matching (matched → notMatched), the feature it backed silently disappears, and nobody notices until production.

WireDoctor snapshots Boot's condition report (every autoconfiguration decision with its condition message) into the baseline, then diffs it across builds:

# application-ci.properties
wiredoctor.baseline=wiredoctor-baseline.json
wiredoctor.fail-on=condition-changed

Workflow for your 3.3 → 4.0 upgrade:

1. On 3.3 (current, known-good): write the baseline (wiredoctor.baseline-write=true), commit it.
2. In the upgrade PR (now on 4.0): CI boots the app, WireDoctor diffs the condition report against the committed baseline.
3. Any autoconfiguration that flipped matched → notMatched (or vice versa) fails the build with the exact condition message — so you see why it stopped matching (missing class, changed property default, new conditional bean…) right in the PR, not in prod.

The condition snapshot is also browsable anytime in the report's Conditions tab (tabbed, filterable). Guide: Upgrade Guard.