gemspec 语义版本控制运算符 ~>(又名 twiddle-wakka ，又名 pessimistic 运算符)允许限制 gem 版本但允许进行一些升级。
我经常看到它可以读作:
"~> 3.1" => "Any version 3.x, but at least 3.1"
"~> 3.1.1" => "Any version 3.1.x, but at least 3.1.1"
但是有了一个数字，这条规则就失效了:
"~> 3" => "Any version x, but at least 3" *NOT TRUE!*
"~> 3" => "Any version 3.x" *True. But why?*
如果我想要“任何版本 3.x”，我可以只使用“~> 3.0”，这是一致的。就目前而言，这种对一个号码的操作更改是不一致的，也没有记录在案。
此外，如果我想说“高于或等于 3 的任何版本”(例如 3.x、4.x 等...)，我很想使用“>=”运算符，我们被告知is evil .
这种行为有原因吗？
编辑:
我把这个交给大卫，因为他在 rubygems 中找到了罪魁祸首文件。有一个“功能”可以默默地将“3”扩展为“3.0”(Line 148 in version.rb:“单位数字版本会自动扩展为零以提供合理的结果。”)
我必须说我不同意结果是合理的，因为它打破了预期的顺序，并且阻止了能够与该运算符(operator)说“任何版本 x，但至少 3”。因此，我们被迫进入 >= which guides.rubygems.org warns us not to use .反正。也许这篇文章将作为我一直在寻找的文档...
最佳答案
通过查看 rubygems 源代码(尤其是 requirement.rb、version.rb)，悲观运算符至少需要两个版本控制段。
这也确实有道理。作为~> v.r只是不等式的语法糖
v.r <= current_version.current_release < (v+1).0
如果只有一个版本号，上限是多少？是的，∞(无穷大)，所以没有必要让它起作用。您可以简单地将其写为 >= v .
关于ruby - 为什么 Gemfile 语义版本控制运算符 (~>) 会产生与一个数字不一致的结果？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24121960/