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 版本会自动扩展为零，以提供合理的结果。