我有一組程序，每個程序都有自己的版本。所有這些程序都依賴於一個庫，同樣也有它自己的版本。例如依賴於庫的程序版本控制
Foo-1.0.3
Bar-2.1.5
Baz-1.3.4
它們取決於libfrobniz-1.4.5。恰巧我必須對圖書館進行一次重大改革（涉及許多重構）。這意味着它會打破一切（Foo，Bar and Baz）。當然，由於這是一個主要的和落後的不兼容的返工，圖書館將會碰到libfrobniz-2.0.0。
我的問題是關於Foo Bar和Baz的版本。我將升級它們以使用libfrobniz-2.0.0，但我沒有改變它們的功能。這三個程序的新版本可以像舊版一樣使用，因此它們完全兼容。但是，它們將依賴於libfrobniz的完全不同版本。你會建議打他們的版本主要數字，或只是補丁程度？
請記住，更改依賴關係的主要編號是最終用戶的主要變化。這絕對不是補丁程序級別，除非你有一個非常好的理由，否則我會說堅持專業。
如果依賴庫暴露了已更改庫中的類型，那麼最終用戶肯定會發生重大變化。也許不是沒有暴露的東西？ – 2009-08-16 22:06:54
不，沒有任何libfrobniz暴露給最終用戶。 – 2009-08-16 22:07:54
確實這種改變類似於重構。我只更改內部（內部是整個庫），但沒有任何最終的軟件功能以任何方式被觸及或改變。 – 2009-08-16 22:10:24
我會保留Foo，Bar和Baz的版本號相同。由於您沒有向這些面向用戶的產品推出新功能或錯誤修復，因此不需要打擾版本號。此外，如果您決定修改版本號，可能會導致用戶混淆。您的用戶可能會疑惑爲什麼您的產品具有新版本的版本號，而沒有任何新的記錄功能或缺陷修復程序。
在三個面向用戶的應用程序中，您可以有一個窗格/窗口，指出產品依賴於libfrobniz並且已升級。
您的版本控制方案取決於您的業務和技術需求。
一些公司每年都會發布「重大」升級以獲得關注和升級的一些收入。他們中的一些人仍然發佈測試版，直到對軟件質量滿意爲止。
準備你自己的計劃，讓你的客戶知道它。 通常，第一個字母是主要版本的主要版本，然後用於改進，然後用於構建和補丁。
這不就是建立一個32位和64位版本的庫相同嗎？ 32位取決於32位庫，而64位取決於64位庫。
按照你會使用類似的東西
規則「當然，因爲這是一個重大的和不向後兼容返工，」
我想起了當年的客戶不得不把所有的力量他們的軟件供應商即將破產，如果該軟件供應商有勇氣打破向後兼容性，拒絕花費任何金錢，直到向後兼容性恢復。
軟件供應商一直承認。
今天，他們似乎可以做任何他們想做的事，而每一位顧客都會盲目追隨他們，有點像來自「1984」的最低階層人士。
但或許我過分悲觀。
編輯
有人指出的情況下，只有一個客戶，我自己。在這種情況下，我不希望有任何需要「版本控制」。這樣的客戶只對一件事情感興趣：軟件可以工作，並且對一個單一版本感興趣：據說與他最新的規格相符。
你知道，有些情況下你自己只有一個客戶。 – 2009-08-16 22:02:59
迴應您的編輯。不是真的。我需要對我使用的內容進行版本控制，因爲如果在三年內，我必須重新計算內容，我必須知道我用來生成該結果的軟件版本。 – 2010-02-23 10:49:18
不是一個笨蛋。您建議的帖子將討論版本控制的具體風格。我在尋求一般規則，並關注我的具體問題。 – 2009-08-16 21:58:25
@Stafano：好吧，這可能是一個騙局，但不是我發佈的那個騙局。 – 2009-08-16 22:04:11
針對我的具體問題重做了這個問題，這正是我現在所關心的問題。 – 2009-08-16 22:04:56