具有不同版本号的rails版本有多不兼容？这些数字的含义是什么？
例如，从版本2.8.7到3.0.1，我们可能会遇到严重的不兼容问题。
但是，版本2.7.1和2.7.2或3.0.6和3.0.7是不兼容的？
答案 0 :(得分：5)
一般来说，数字的变化越大，核心的变化就越大。 因此，2.8.7到3.0.1将是一个重大变化，因为我们从Rails 2转到Rails 3（实际上是一个非常大的变化）。
另一方面，2.7.1至2.7.2将是一些小修复。
正如DHH自己所说，只要有很好的想法，Rails总是愿意100％改变它的核心。所以，你可以想象，2到3或3到4最有可能敲响巨大变化的钟声。
答案 1 :(得分：0)
图书馆以三种方式改变（嗯，更多 超过3，但请保持专注！）。
- 此更改可能只是一个实施细节，对此没有影响 客户端软件。
- 此更改可能会添加新功能，但会以客户端的方式执行此操作 写入早期版本的软件 仍然兼容。
- 更改可能会以这种方式更改库的公共接口 那个旧软件不再存在 兼容。
RationalVersioningPolicy提供 以下准则：
版本应由三个代表 非负整数，用。分隔 期间（例如3.1.4）。
第一个 整数是'''主要'''版本 数字，第二个整数是 '''minor'''版本号，和 第三个整数是'''build''' 数。
第1类更改 （实施细节）将增加 内部版本号。
第2类更改 （向后兼容）将递增 次要版本号并重置 编号。
第3类更改 （不兼容）将增加 主要编号并重置未成年人 并建立数字。任何''公共'' 释放一颗宝石应该有一个 不同的版本。通常意味着 递增内部版本号。这个 意味着开发人员可以生成构建 整天为自己，但很快 当他/她公开发布时， 版本必须更新。
就是这样。这不是太难。
Additionaly。谁对这个答案感兴趣也可能对Pessimistic Version Constraint
感兴趣