依存関係のアップグレード後のプロジェクトのバージョン管理のベストプラクティス
たとえば、私のプロジェクトにはバージョン1.0.0の依存関係Nがあります。その後、何かが変更されました。私は新しいバージョンに依存する必要があります-1.0.1にします。
OK、依存関係のバージョンを増やしていますが、コードに変更はありません。自分のプロジェクトのバージョンをインクリメントする必要があるようですが、どのくらい正確にインクリメントする必要がありますか？
3番目の数値だけを増やすべきですか（いわゆるリビジョン）、またはここでのベストプラクティスはより複雑です。たとえば、プロジェクトの依存関係のマイナーバリューを変更する場合、プロジェクト自体で同じことを行う必要がありますか？
私はこの状況のベストプラクティスを認識していないので、ここに私の見解を示します。
更新された依存関係は、バージョンに反映されているはずです。 MAJOR.MINOR.REVISION採番スキーマの例を見てみましょう。
依存関係のバージョンを変更すると、少なくともREVISION番号が増加しますが、依存関係バージョンのMAJORまたはMINORの変更などの大きな変更により、MINORバージョンが増加します。
依存関係のメジャーバージョンの変更にはAPIの変更が伴うことがよくありますが、依存関係の新しいメジャーバージョンに更新する以上の変更を加えない限り、自分のメジャーバージョンをインクリメントしません。
セマンティックバージョニング は、バージョン番号が機能する方法を体系化する試みです。
一言で言えば：
バージョン番号MAJOR.MINOR.PATCHを指定して、次の値を増やします。
- 互換性のないAPI変更を行った場合のメジャーバージョン
- 下位互換性のある方法で機能を追加する場合のマイナーバージョン
- 下位互換性のあるバグ修正を行う場合のパッチバージョン。
これによると、最終製品の変更がコードの変更によるものか、依存関係の変更によるものかは気にする必要はありません。機能を追加する場合は、マイナーバージョンを変更し、追加しない場合は、パッチバージョンを変更します。変更がまったくない場合（変更された依存関係の一部を使用していない可能性があります）、私はあなたがそうではないと思いますバージョン番号を更新する必要があります。
依存関係のみを更新している場合、それはマイナーリビジョン（コードへの変更はほとんどありません）なので、3番目の数値のみを更新します。 2番目の数字は通常、メジャーアップデート（大きなバグ修正、新機能、バランスの問題など）用に予約されており、最初の数字は完全に新しいバージョンのソフトウェア用です。