Glossary · Change, versions and configuration
Breaking change
In systems engineering, a breaking change is a change that may invalidate existing interfaces, behavior, tests, assumptions, documentation or evidence. It is defined by its possible effect on dependents, not by the size of the change.
- Data and interfaces
- Systems engineering
- Verification
In one sentence
A breaking change can invalidate interfaces, tests, documentation and safety evidence at once, so it needs impact analysis before release.
Example
Renaming the unit of a conveyor speed value from m/min to m/s in a line controller is a breaking change, even though only one field changed, because every consumer of the value would misinterpret it.
How it applies
- Integrated systems: Classify every change against its dependents. If any consumer, test or document may no longer be valid, treat the change as breaking and run an impact analysis.
- Evidence: A breaking change can invalidate verification results and safety claims that were valid for the previous version. Mark them for review instead of carrying them forward.
- Technical documentation: Instructions, interface documents and training material are dependents too. Include them in the change propagation.
- Change management: Prefer a deprecation path with a transition period over an unannounced break.
Breaking change vs. substantial modification
A breaking change is an engineering classification of effects on dependents. A substantial modification is a regulatory concept about whether a modified machine must be reassessed. A breaking change can, but does not have to, lead to a substantial modification.