ruby gem add_dependency 中版本限制的推荐做法是什么？答案

【问题标题】：What is reccomended practice for version restrictions in rubygem add_dependency?ruby gem add_dependency 中版本限制的推荐做法是什么？
【发布时间】：2019-10-07 17:44:02
【问题描述】：

在创作 gem 时，对于依赖项的版本限制，推荐的做法是什么。例如，我知道我的 gem 适用于 rubyzip 2.x 版，但我也知道它也适用于 1.9。我应该说

spec.add_runtime_dependency 'rubyzip', '>1.8'

或者如果 rubyzip 版本 1.9 已经过时了，更常见的是为 2.x 行“推送”更改？此外，如果我使用上述行，我可能会冒与未来版本不兼容的风险，但另一方面，请将 coice 留给用户。

注意：问题是一般性的，对 rubyzip 的依赖只是一个例子。

【问题讨论】：

'>=1.9', '<3'怎么样
至于接近投票 - 我要求最佳实践，通常不仅包含意见，还包含安全性、“最小惊喜”、可用性等参数。这个问题也很有价值，因为答案不包含在任何现有文档中（我知道）。

标签： ruby rubygems version gemspecs

【解决方案1】：

如果您知道您的 gem 可以与 rubyzip 1.9 一起使用，那么真的没有必要强制人们使用 >=2.0。

当然，更新依赖项对于您的库用户来说是一个好主意，但“更新您的软件警察”不是您的工作！

通常建议指定版本必须为< 3（尽管开发人员并非始终如一地这样做），因为存在一个合理的风险，即主要的依赖版本会与您的代码的此版本不兼容。

所以，作为一种妥协，你可以这样做：

spec.add_runtime_dependency 'rubyzip', '>=1.9', '<3'

有关有效语法示例，请参阅 the documentation。

【讨论】：

我知道可能的语法，问题更多是关于这是否是推荐的策略。是否建议让依赖关系尽可能宽？
我已经回答过了。不，通常最好至少在主要版本上设置一个上限。否则，在升级项目中的大量依赖项时，要找出错误的原因可能会非常困难。
例如看the gemspec for bundler; the most heavily downloaded ruby gem。一些依赖项（故意）更加严格，但它们都没有上限。
有例外；使用您自己的最佳判断。
@gorn "我怀疑它们不兼容..." -- 如果它们不是不兼容的，那么是的，在我看来，那将是一个更“社区-友好”的设计。但我不知道你关于兼容性的假设是否属实。