breaking change とは？ Stackoverflowより。
Q:私たちの会社では、壊れるような変化(breaking change)とは何かという定義があり、なるべく避けようと思っています。
それは、「変化」です。
- メソッドのシグネチャを変更するもの。
- メソッドの動作を変更する。
- 設定やコンフィギュレーションを変更する。
- モジュールやアセンブリなどの依存関係を追加する。 これは、ブレークチェンジの定義として適切なものでしょうか？何か欠けているものはないでしょうか？データベーススキーマの変更もブレークチェンジと言えるでしょうか（新しいカラムや新しいテーブルなど）？
A:最初のポイントは、「breaking change」が英語*で何を意味するのかを決めることです。ある場所では、単にコードのコンパイルや実行を停止させるものである場合もあります。
あなたのこれまでのリストからは、他の人が対応する変更をする必要があるような変更のことを指しているのでしょう。その場合、製品の各モジュールは明確に定義されたインターフェース（他のモジュール、パブリックRESTインターフェース、システムのファイルシステム、gui、ウェブアプリなど）を持っているはずなので、これらのインターフェースの1つから何かを取り除く（あるいは、それらの使用に関する新しい要件を追加する）ような変更が壊れる変更となります - 実質的には、製品の前のバージョンを使って、変更のあるモジュールだけを交換できない場合、それは壊す変更となります。
つまり、データベースの変更は、通常、破壊的な変更となります（必要に応じて自動アップグレードや自動ダウングレードを行うコードがある場合を除く）。
モジュール内の変更や、文書化されていないインターフェース（つまり、使ってはいけないもの）の変更は、壊れるような変更ではありません。もし、そのようなことが原因で製品が壊れてしまうのであれば、それはカプセル化の失敗である。
*または、あなたの（人間の）選択した言語です。
↑出典
アルクの説明
《a ～》《コ》〔バージョンアップなどにおける〕互換性を破る変更
引用元
コメント
DeepLの「breaking change」の訳がいまいちだったので。。。
