ライブラリに依存したプログラムのバージョン管理

Question

私はそれぞれ独自のバージョンのプログラムを持っています。これらのプログラムはすべて、ライブラリに依存しています。また、独自のバージョンもあります。例えば、

Foo-1.0.3 
Bar-2.1.5 
Baz-1.3.4 

libfrobniz-1.4.5に依存します。私はライブラリの大幅な見直し（多くのリファクタリングを伴う）をしなければならないことが起こります。これはすべてが壊れることを意味します（Foo、Bar、Baz）。もちろん、これは主要で後方互換性のないリワークなので、図書館はlibfrobniz-2.0.0にバンプされます。

私の質問は、Foo BarとBazのバージョンに関連しています。 libfrobniz-2.0.0を使用するようにそれらをアップグレードしますが、私はその機能を変更しません。これらの3つのプログラムの新しいバージョンは、古いものとまったく同じように使用でき、したがって完全に互換性があります。ただし、彼らはlibfrobnizの完全に異なるバージョンに依存します。彼らのバージョンのメジャー番号、またはパッチレベルだけをバンプすることを提案しますか？

Answer 1

依存関係のメジャー番号を変更することは、エンドユーザーの大きな変更であることに注意してください。それは間違いなくパッチのレベルではない、と私はあなたが非常に良い理由がない限り、メジャーとスティックと言うだろう。

Answer 2

私はFoo、Bar、Bazのバージョン番号を同じにしておきます。これらのユーザー向け製品に新しい機能やバグ修正を導入しているわけではないので、バージョン番号にバンプする必要はありません。さらに、バージョン番号をバンプすることに決めた場合、ユーザーの混乱を招く可能性があります。あなたのユーザは、あなたの製品がなぜ新しい文書化された機能やバグ修正なしで新しいバージョンのバージョン番号を持っているのか不思議に思うかもしれません。

3つのユーザー向けアプリケーションの中には、製品がlibfrobnizに依存し、アップグレードされていることを示すウィンドウ/ウィンドウがあります。

Answer 3

お客様のバージョニングスキームは、ビジネスと技術的なニーズによって異なります。

一部の企業では、毎年大規模なアップグレードがリリースされています。 ソフトウェアの品質に満足するまで、まだベータ版をリリースしている人もいます。

独自のスキームを準備し、顧客にそれを知らせる。 通常、最初の文字は大きな変更のための主なバージョン番号であり、次に改良のためのものであり、ビルドとパッチのものです。

Answer 4

これは32ビット版と64ビット版のライブラリをビルドするのと同じではないでしょうか？ 32bitは32bitのlibsに依存し、64は64bitのlibsに依存します。

「これは主要な後方互換性のないリワークであるから、もちろん、」私は、顧客のいずれかをもたらす力を持っていた時間を覚えて

をあなたはその

Answer 5

のようなもののために使用するルールに従ってください下位互換性が回復するまでお金を使うことを拒否することによって、そのソフトウエアサプライヤが下位互換性を破る神経を持っていれば、彼らのソフトウェアサプライヤは破産に近づく。

ソフトウェアのサプライヤは常に認めています。

今日、彼らは彼らが望むものを何でもすることができるように思えます、そして、すべての顧客はただ頭脳無しに彼らに従います、ちょうど "1984"からの最も低い階級の人々のように。

しかし、おそらく私は過剰悲観的です。

EDITは

誰かが唯一の顧客、自分がそこにある場合を指摘しました。その場合、私は "バージョン管理"の必要性はないと思います。そのような顧客は、ソフトウェアが動作し、ちょうど1つの単一のバージョンに興味を持っているという、まさに1つのことに興味を持っています。