Ruby Version類用法及代碼示例

Version 類將字符串版本處理為可比較的值。版本字符串通常應該是一係列用句點分隔的數字。每個部分(用句點分隔的數字)都被認為是自己的編號，這些用於排序。例如，3.10 排序高於 3.2，因為 10 大於 2。

如果任何部分包含字母(目前僅支持a-z)，則該版本被視為預發布。第 N 部分中包含預發布部分的版本排序少於包含 N-1 部分的版本。預發布部分使用普通的 Ruby 字符串排序規則按字母順序排序。如果預發布部分同時包含字母和數字，它將被分成多個部分以提供預期的排序行為(1.0.a10 變為 1.0.a.10，並且大於 1.0.a9)。

預發行版在真實發行版之間排序(最新到最舊)：

1. 1.0

2. 1.0.b1

3. 1.0.a.2

4. 0.9

如果您想指定包含 1.x 係列的預發布和常規發布的版本限製，這是最好的方法：

s.add_dependency 'example', '>= 1.0.0.a', '< 2.0.0'

軟件如何變化

用戶期望能夠指定一個版本約束，讓他們有一些合理的期望，即如果版本約束為真，庫的新版本將與他們的軟件一起工作，如果版本約束為假，則不能與他們的軟件一起工作。換句話說，完美的係統會接受庫的所有兼容版本並拒絕所有不兼容的版本。

庫以 3 種方式變化(嗯，不止 3 種，但請保持專注！)。

1. 更改可能隻是一個實現細節，對客戶端軟件沒有影響。

2. 該更改可能會添加新函數，但這樣做的方式是使寫入早期版本的客戶端軟件仍然兼容。

3. 更改可能會以舊軟件不再兼容的方式更改庫的公共接口。

在這一點上，一些例子是合適的。假設我有一個 Stack 類，它支持 push 和 pop 方法。

第 1 類變更示例：

• 從基於數組的實現切換到基於linked-list 的實現。

• 為大型堆棧提供自動(和透明)的後備存儲。

第 2 類更改的示例可能是：

• 添加 depth 方法以返回堆棧的當前深度。

• 添加一個 top 方法，該方法返回當前堆棧頂部(不更改堆棧)。

• 更改 push 以便它返回推送的項目(以前它沒有可用的返回值)。

第 3 類更改的示例可能是：

• 更改 pop 使其不再返回值(您必須使用 top 來獲取堆棧頂部)。

• 將方法重命名為 push_item 和 pop_item 。

RubyGems Rational 版本控製

• 版本應由三個非負整數表示，以句點分隔(例如 3.1.4)。第一個整數是“major” 版本號，第二個整數是“minor” 版本號，第三個整數是“build” 號。

• 1 類更改(實施細節)將增加內部版本號。

• 第 2 類更改(向後兼容)將增加次要版本號並重置內部版本號。

• 第 3 類更改(不兼容)將增加主要內部版本號並重置次要版本號和內部版本號。

• gem 的任何“public” 版本都應該有不同的版本。通常這意味著增加內部版本號。這意味著開發人員可以整天生成構建，但是一旦他們公開發布，版本就必須更新。

例子

讓我們使用上麵的 Stack 示例來完成項目生命周期。

Version 0.0.1

最初的 Stack 類是 release。

Version 0.0.2

切換到linked=list 實現，因為它更酷。

Version 0.1.0

添加了 depth 方法。

Version 1.0.0

添加了 top 並使 pop 返回 nil(pop 用於返回舊的頂部項目)。

Version 1.1.0

push 現在返回推送的值(它使用它返回 nil)。

Version 1.1.1

修複了鏈表實現中的一個錯誤。

Version 1.1.2

修複了上次修複中引入的錯誤。

客戶端 A 需要一個具有基本推送/彈出函數的堆棧。他們寫入原始接口(沒有 top )，所以他們的版本約束看起來像：

gem 'stack', '>= 0.0'

從本質上講，客戶端 A 的任何版本都可以。對庫的不兼容更改會讓他們感到悲傷，但他們願意冒險(我們稱客戶端 A 樂觀)。

客戶端 B 和客戶端 A 一樣，除了兩件事：(1)他們使用 depth 方法，(2)他們擔心未來的不兼容，所以他們這樣寫他們的版本約束：

gem 'stack', '~> 0.1'

depth 方法是在 0.1.0 版本中引入的，因此該版本或更高版本都可以，隻要該版本低於引入不兼容性的 1.0 版本即可。我們稱客戶 B 悲觀，因為他們擔心未來的變化不兼容(悲觀是可以的！)。

防止 Version 災難：

從：blog.zenspider.com/2008/10/rubygems-howto-preventing-cata.html

假設您依賴 fnord gem 版本 2.y.z。如果您將依賴項指定為“>= 2.0.0”，那麽您很好，對吧？如果 fnord 3.0 出現並且不向後兼容 2.y.z 會發生什麽？你的東西會因為使用“>=”而壞掉。更好的方法是使用 “approximate” 版本說明符 (“~>”) 指定您的依賴項。它們有點令人困惑，所以這裏是依賴說明符的工作方式：

Specification From  ... To (exclusive)
">= 3.0"      3.0   ... ∞
"~> 3.0"      3.0   ... 4.0
"~> 3.0.0"    3.0.0 ... 3.1
"~> 3.5"      3.5   ... 4.0
"~> 3.5.0"    3.5.0 ... 3.6
"~> 3"        3.0   ... 4.0

對於最後一個示例，single-digit 版本會自動擴展為零，以提供合理的結果。