Backward Compatibility in MSBuild

Backward compatibility is the default — any change that could alter existing build behavior must be explicitly justified.

This skill covers how to evaluate compatibility risk. For the mechanics of ChangeWave implementation, see the changewaves skill.

Core Philosophy

1. Existing builds must not break. If a project built successfully yesterday, it must build successfully today with identical semantics.
2. New warnings are breaking changes. Builds that use -WarnAsError or <TreatWarningsAsErrors>true</TreatWarningsAsErrors> will fail if you introduce a new warning. Always gate new warnings behind a ChangeWave or emit them as Message importance instead.
3. Output changes are behavioral changes. Even "improvements" to output formatting, file paths, or diagnostic text can break downstream consumers that parse MSBuild output.
4. Removal is nearly impossible. Never remove CLI switches, public APIs, or property names. Deprecate with warnings first, then gate removal behind a ChangeWave after multiple release cycles.

Blast Radius Checklist

Before merging any behavioral change, evaluate: