関連するライブラリのアップグレード時の（アプリケーションへの）セマンティックバージョンの変更
したがって、14の異なるライブラリを利用するアプリケーションがあります。私がこのアプリケーションを更新してからしばらく経ち、関連する1つ以上のライブラリでmajorリビジョン（セマンティックバージョニングを使用）が発生しました。そうは言っても、これらのライブラリの最新バージョンをすべて利用するようにアプリケーションを更新しました。
さらに、プロジェクトに関係するライブラリが経験した大きな変更の1つは、インターフェイスメソッド名が変更されたことです。アプリケーションはそのインターフェイスメソッドを使用していたので、新しいライブラリに一致するように関数が呼び出されたところはどこでも変更する必要がありました。これはライブラリのmajor変更ですが、これはnotがアプリケーションのリビジョンに大きな変更を加えたものだと思います。
私の推論は正しいですか？アプリケーションはどのような改訂を取得しますか？
セマンティックバージョニングルールは、ユーザーの観点からソフトウェアに適用されます。 APIが変更されており、下位互換性がない場合は、メジャーバージョン番号を更新する必要があります。しかし、そうではないようです。 APIは変更されていないようです。以前のバージョンを使用していたクライアントは、他の変更を加えることなく、新しいバージョンをそのまま使用できます。これはマイナーバージョンの増加になります。
これは セマンティックバージョニングFAQ で確認されています：
パブリックAPIを変更せずに自分の依存関係を更新した場合はどうすればよいですか？
パブリックAPIには影響しないため、互換性があると見なされます。パッケージと同じ依存関係に明示的に依存するソフトウェアは、独自の依存関係の仕様を持つ必要があり、作成者は競合に気付きます。変更がパッチレベルかマイナーレベルの変更かは、バグを修正したり新しい機能を導入したりするために依存関係を更新したかどうかによって決まります。通常、後者のインスタンスには追加のコードが必要ですが、その場合は明らかにマイナーレベルの増分になります。
コメントに基づいて、アプリケーションにセマンティックバージョニングを使用しているようです。これは一般的な使用例ではありません。セマンティックバージョニングは、APIとライブラリ用に設計されています。ソフトウェアエンジニアリングスタック交換に関する別の質問 アプリケーションでのセマンティックバージョニングの使用に対応 。
GUIベースのアプリケーションのインスタンスでは、GUIはパブリックインターフェイスです。私はこのような定義を使用します：
- ユーザーのワークフローまたはユーザーが下位互換性のない方法でソフトウェアを操作する方法を変更する場合のメジャーバージョン。
- 下位互換性のある方法で機能を追加する場合のマイナーバージョン
- 下位互換性のあるバグ修正を行う場合のパッチバージョン。
既存のワークフローを変更せずに機能を追加すると、それはマイナーバージョンになります。既存のワークフローを変更する場合、それはメジャーバージョンです。パッチバージョンは、ユーザーがソフトウェアを操作する方法を変更しないバグ修正です。
ライブラリのパブリックインターフェイスでパブリックメソッド名を変更した場合は、はい。これはメジャーバージョンの変更です。
どうして？ライブラリをアップグレードするユーザーは、古いメソッド名のいずれかを使用した場合、コンパイルしないコードが含まれるためです。
通常、独自のコードで参照するサードパーティライブラリはライブラリのユーザーには公開されないため、メジャー/マイナー変更があるかどうかに関係なく、コードのポイントリリースのみが必要になります。
おそらくnotサードパーティのライブラリの命名方式に合わせるためにインターフェースを変更するのは良い考えでした