Backwards compatibility could relate to API or behavior or features.
Since we generally follow semantic versioning, backwards incompatible changes should be made in major releases, when the major version is changed, i.e. ITK 4 to ITK 5 as noted by @dzenanz. This helps users have an expectation that they can upgrade feature releases without many issues but expect that a few changes may be needed for updates to the major version.
Backwards incompatible changes should be accompanied by a note in the migration guide.
A deprecation warning should be added and kept around nominally until the next major release. However, this depends on how widely adopted the behavior was and its impact - it could be longer or shorter or not at all.