Glossary
Breaking Change
A breaking change is any modification that requires consumers of the software to change their own code, configuration, or workflow to keep things working after they upgrade.
Breaking changes are the changes that cannot be adopted silently. Removing an API endpoint, renaming a configuration key, changing a default value, or altering the shape of a response can all break the code that depends on the old behavior. Under semantic versioning, any breaking change requires incrementing the major version, for example from v2.4.0 to v3.0.0.
In release notes and changelogs, breaking changes deserve special prominence. Best practice is to place them at the very top of the note, label them clearly, state exactly what the reader must do, and link to a migration guide when one exists. Burying a breaking change inside a long list is one of the fastest ways to generate frustrated support tickets.
In Conventional Commits, a breaking change is declared with an exclamation mark after the type, as in 'feat!: drop Node 16 support', or with a 'BREAKING CHANGE:' footer that describes the impact and the migration path. Both signals tell tooling to bump the major version automatically.