一部のソフトウェアにはファイル名の一部としてバージョン番号が含まれているが、他のソフトウェアには含まれていないことがわかります。私は後者のタイプに慣れていますが、それはより人気があると思いますが、前者のタイプはJavaScriptライブラリーで時々見られます。たとえば、jQueryのファイル名はjquery-2.1.0.js
の代わりに jquery.js
。これらのタイプのファイルを更新するときはいつでも、これらのファイルをロードする他のプログラムの場所を探し、それらが参照するファイル名を変更し、これらのライブラリの古いバージョンを手動で削除する必要があります。これは私にとって不便なので、ファイルの名前を変更してバージョン番号を除外し、参照されるファイル名にはバージョン番号を含めないようにします。
これらの数値はある種のバージョン管理用であると思われますが、いつどのように使用されるかは不明です。
必要なバージョンを指定することは理にかなっています。依存する可能性のある動作は変更されている可能性があるため、新しい方が常に良いとは限りません。まず、新しいバージョンのライブラリが機能するかどうかをテストします。次に、明示的に更新します。
Webリソースの場合、バージョンをファイル名の一部にすることはcachingのコンテキストでは重要です。 jquery.js
などの静的リソースの場合、再フェッチする前に非常に長いキャッシュ時間が必要になります。ただし、更新中は、クライアントが翌日などに新しいバージョンに切り替えるのではなく、コードで新しいバージョン即時を使用する必要があります。 foo-1.2.3.js
はfoo-1.2.4.js
とは異なるリソースであるため、キャッシュが邪魔になることはありません。
(@amonで言及されているWebキャッシュの状況を除く):プログラムで使用するためにサードパーティライブラリのローカルコピーを作成することを想定しています。それ以外の場合は、バージョン番号の必要性は明らかです。開発中のソフトウェアシステム内でのこのようなサードパーティライブラリの使用シナリオは、次の2つのいずれかです。
libを使用しているプログラムのすべての部分は、常に同じバージョンのlib(理想的には「最新」)を共有し、ユーザーは随時libを更新します。次に、バージョン番号をファイル名の一部として保持するのは非常に退屈な作業になる可能性があります。実際には、可能であればファイルのローカルコピーから番号を取り除くことをお勧めします。これは、サードパーティベンダーがlibを以前のバージョンとほとんど下位互換性を維持していると確信している場合にのみ、良いアイデアであることに注意してください。
バージョンAを必要とするプログラムの一部と、バージョンBを必要とするその他の部分があると予想します。その場合、サードパーティのlibのバージョン番号が明らかに必要になります。この状況は、新しいバージョンを導入した後、libを使用してすべてのソフトウェアパーツを一度に簡単にテストできない場合にも発生する可能性があることに注意してください。
自分がライブラリベンダーである場合は、デフォルトでバージョン番号を含める必要がありますが、そのlibのユーザーがその番号を保持するか削除するかを自分で決めることができます。