myLib-1.1.0 というプロジェクトがあるとします。このプロジェクトは lib-dependency-1.2.3 に依存しています。
この依存関係の新しいバージョンがあり、それを使用する必要がある場合、プロジェクトのバージョンも変更する必要がありますか? myLib に対してその他の変更は行われません。
同時に、myLib は他のさまざまなプロジェクトの依存関係です。私の主な懸念は、依存関係の小さな変更が上流に与える影響です。
myLib-1.1.0 というプロジェクトがあるとします。このプロジェクトは lib-dependency-1.2.3 に依存しています。
この依存関係の新しいバージョンがあり、それを使用する必要がある場合、プロジェクトのバージョンも変更する必要がありますか? myLib に対してその他の変更は行われません。
同時に、myLib は他のさまざまなプロジェクトの依存関係です。私の主な懸念は、依存関係の小さな変更が上流に与える影響です。
はい。Maven では、リリースされたバージョンは不変です。lib-dependency-1.2.3 に依存する 1.1.0 をリリースする場合は、それだけです。
lib-dependency-1.2.4 に依存するように変更した場合、それは新しいバージョンです。1.1.0 を再デプロイしないでください。1.1.0 (不変と思われる) を既にプルしている可能性があるためです。つまり、新しい修飾子 (たとえば、myLib-1.1.0-RC-2 ですが、1.1.1 だけの方がよい) であっても、別のバージョンが必要です。
Maven は、ローカル リポジトリにリリース バージョンがあると、リモート リポジトリのリリース バージョンを再チェックしません。そのため、誰かが既に 1.1.0 をローカルに持っている場合、新しい修正済みの 1.1.0 を取得することはできません。
そして、波紋の問題について。上流のプロジェクトは、受け入れ可能な最も低いリリース バージョンに依存する必要があります。つまり、アップストリーム プロジェクト自体が (間接的に) lib-dependency-1.2.4 を必要としないため、myLib-1.1.0 で問題ない場合は、1.1.0 のままにする必要があります。
動作に影響を与える可能性のあるコードの変更には、新しいバージョン番号を付ける必要があります。つまり、絶対に些細な変更ではないものには、新しいバージョン番号を付ける必要があります。依存関係の完全なコード検査を行わない限り、完全に些細な変更のみを行ったと仮定する理由がないため、変更された依存関係は間違いなくその資格があります。
変更は「小さな」ものとして宣伝されることがよくありますが (上で私が呼んでいるように、まったく些細なことと同様です)、ほとんどそうではありません。誰かのユースケースでは無視できるかもしれませんが、他の誰かのユースケースではそうではありません。私は、プロジェクト内の Javadoc にのみ変更を加えただけで、事態が悪化する状況を見たことさえあります。(誰かが Javadoc にそれほど強く依存することがどれほど賢明であるかについて議論することもできますが、それは重要なことではありませんよね?)
変更を蓄積して、それらの束を 1 つのリリースとしてリリースできないと言っているわけではありません。蓄積している間、プロジェクトは流動的であり、...-SNAPSHOT
バージョンが必要です。少しでも変更されたmyLib-1.1.0
( のない)の 2 つのバージョンがあってはなりません。-SNAPSHOT
プロジェクトを再リリースしているという事実は、回帰テストなどをやり直して、依存関係の変更でまだ機能していることを検証する必要があるという事実も明確にします。