为什么要使用嵌套的Ruby模块来获取版本信息？

最近我一直在看一些gems的源代码。我一直看到的一个习惯用法是使用嵌套模块，该模块包含连接到版本字符串中的版本常量，即围绕此类内容的变体：

module ChunkyBacon
  module Version
    MAJOR = 0
    MINOR = 6
    TINY  = 2
  end

  VERSION = [Version::MAJOR, Version::MINOR, Version::TINY].compact * '.'
end

以这种方式存储库版本信息有什么好处（如果有的话）？为什么不干脆做：

module ChunkyBacon
  VERSION = '0.6.2'.freeze
end

---

对于编程兼容性检查，更容易使用显式分隔的版本号

e、 g:

---

在字符串中包含版本信息通常是个坏主意

例如，不可能有Ruby 1.10，因为如果Ruby_VERSION>'1.6'测试兼容性的应用程序太多，就会出现故障。（因为从词典学的角度来看，

1.10<1.6

）这就是为什么会有这样一个复杂的方案，通常的Ruby 1.9.x是Ruby 1.9.0-x，而Ruby 1.10.x现在是Ruby 1.9.x+1。因此，即将发布的Ruby版本，即Ruby 1.9.2，看起来是一个不稳定的开发版本，实际上是Ruby 1.10.1，这是一个生产版本

这导致了很多混乱。例如，即使是许多经验丰富的Ruby社区领导人，仍然在散布Ruby 1.9是开发版本的错误信息，尽管版本控制策略的变化已经得到了广泛的宣传

Opera web浏览器是另一个例子。Opera 10.0发布时，最初也报告了其版本号10.0。然而，在测试期间，很明显，许多网站，其中包括非常大和受人尊敬的网站，完全崩溃了，因为Opera是有史以来第一个达到10.0的主流浏览器，这些网站正在进行简单的字符串比较，因此认为他们在处理Opera 1.0，它不支持JavaScript或CSS。唯一可行的解决方案是Opera10.0的最终版本打印9.80作为版本号

MarkRussinovich在MicrosoftPDC上介绍Windows7内核时，也对比较版本号大发雷霆。他向观众解释为什么Windows7的版本号在早期版本中是7，而在发布版本中是6.1。原因是许多应用程序要么降级，要么根本无法工作。有些人会简单地检查

，如果major==6，则检查增强的_vista_模式，否则检查糟糕的_xp_模式

，这意味着他们将在Windows7中降级运行。其他人则更具攻击性，比如说

如果主修==6，则采用增强的vista模式如果主修==5，则采用蹩脚的xp模式，否则不支持windows版本

，他们会拒绝工作。（这当然是愚蠢的，因为Windows7与Vista完全向后兼容。）

因此，微软将版本号改为6.1，Russinovich半开玩笑、半悲伤、半认真地说，这显然意味着Windows8的版本号必须是6.1.1。等等

---

所以，长话短说：程序员太蠢了，不能自己解析版本号，你必须为他们解析。

Aha！我没想到。谢谢。值得注意的是Ruby本身就是按照你的建议做的。在irb尝试“版本”；-）@彼得，你确定吗？对于版本，我得到“没有常量初始化”，对于RUBY_版本，我得到一个字符串。@banister啊，还有一个1.8对1.9的区别；-）幸运的是，1.8.x还支持RUBY_版本。

require 'chunkybacon'
if ChunkyBacon::VERSION::MAJOR > 0
  # barf
end