のような API を介して呼び出すことができる関数があるとしましょう。$MyFunction簡潔にするため$MyFunctionに 12 を返します。名前を に変更$MyFunctionし$The12Functionても、同じ結果が返されるとしましょう(この例では整数 12)。これは、メジャーまたはマイナーの SemVer バージョン番号へのバンプを保証しますか?
$MyFunction動作しなくなったため、下位互換性を許可していないと主張する人もいるかもしれません。ただし、 を介して同じ結果を返すことができるため、下位互換性があると主張することもできます$The12Function。
バージョン番号 MAJOR.MINOR.PATCH を指定すると、次の値がインクリメントされます。
互換性のない API の変更を行った場合のメジャー バージョン、
下位互換性のある方法で機能を追加する場合の MINOR バージョン、および
下位互換性のあるバグ修正を行う場合の PATCH バージョン。
したがって、あなたの場合、古い関数名も維持しない場合は、古いバージョンの API との互換性を維持するために、メジャー バージョン番号を増やす必要があります。
互換性が壊れているかどうかを確認する 1 つの方法は、API と機能が、この機能を他のプログラムに提供するライブラリにカプセル化されていると想像することです。次に、その API に変更を加えます。新しいバージョンのライブラリを使用するために、古いバージョンの API にリンクされたプログラムを変更する必要がある場合は、互換性が失われているため、メジャー バージョンを変更する必要があります。非推奨の古い関数呼び出しをオーバーライドして維持することでこの問題を解決できますが、API の複雑さが増します。