13

この質問は、C や Java などの 1 つの言語 (「ソース」) で記述され、動的リンクを使用してマシン コードや Java バイト コードなどの別の言語 (「バイナリ」) で配布されるすべての言語に適用されます。

ユーザーが既に私のライブラリのバージョン A を使用しているとします。新しいバージョン B をリリースします。

B に対して変更せずにコードをコンパイルし、B で正しく実行できる場合、A から B への変更はソース互換性があると言われます。

A に対してコードをコンパイルし、B で正しく実行できる場合、A から B への変更はバイナリ互換性があると言われます。この状況は、分離されたモジュールのロード (OSGI など) なしで推移的な依存関係グラフを使用する場合によく見られます。X は Y および Z の特定のバージョンに対してコンパイルされ、Y は別の特定のバージョンの Z に対してコンパイルされます。実行時に、Y の Z への呼び出しは正しくない可能性があり、クラッシュする可能性があります。

変更がソース互換であっても、バイナリ互換でない可能性があります。変更がソース互換性がなく、バイナリ互換性がある可能性もあります。

セマンティック バージョニングにはどの互換性を使用しますか? メジャー アップデートとマイナー/パッチ アップデートを区別するためにソース互換性を使用しますか? または、メジャー アップデートとマイナー/パッチ アップデートを区別するためにバイナリ互換性を使用しますか?

私の現在の動機は、Scala ライブラリです。Scala バイナリ互換性は分析が非常に難しく、コンパイラの詳細をよく理解している必要があります。ソースの互換性とバイナリの非互換性は非常に一般的です。

これは奇妙なエッジ ケースではありません。この問題は、ほとんどすべてのコンパイル済みの動的にリンクされた言語で発生する可能性があります。

4

2 に答える 2

12

数か月後、良い結論が得られたと思います。

セマンティック バージョニングでは両方を考慮し、「最も変更された」ものに従う必要があります。

  • ソース コンパイルの中断は、ライブラリのユーザーにとって互換性のない変更です。
  • ランタイム実行の中断は、ライブラリのユーザーにとって互換性のない変更です。

ソースの互換性またはバイナリの互換性が変更された場合、セマンティック バージョニングに従って、新しいメジャー バージョンにする必要があります。

私の Scala の場合、バイナリ互換性を判断するのがかなり難しい場合があります。JDiffなど、いくつかの JAR API 差分ツールがあります。

于 2015-12-10T05:44:43.847 に答える
0

この質問に答えるには、あなたがプログラマーではないユーザーであると仮定してください。彼らの観点からすると、ソース コードは無価値です。彼らはそれを理解しておらず、彼らにとって無意味です。一方、彼らはオブジェクト コードを含むファイルを持っており、それをどこかに移動する必要があることを知っています。バイナリのバージョンだけが重要です。

しかし、これで話は終わりではありません。あなたの質問には、はるかに優れた回答の核が暗黙的に含まれています。互換性には 2 種類あるため、2 つのバージョン シーケンスが必要です。質問自体には、機能不全の仮定が含まれています。つまり、バージョン シーケンスは 1 つだけである必要があります。

ここで、2 つのバージョン シーケンスがあり、さらにユーザー エンドでソース互換バージョンをオブジェクト互換バージョンに自動的に変換する方法を作成すると、問題が軽減されます。これを行うには、コンパイラのバージョン、インタープリターのバージョン、コマンド ライン引数など、変換の方法を明示的に指定する必要があります。

要するに、上記の質問に対する最良の答えは、それが両方に当てはまるということです。

于 2015-12-03T15:58:10.603 に答える