Rails 版本数字的含义是什么?

发布于 2024-11-03 23:08:50 字数 141 浏览 2 评论 0原文

不同版本号的 Rails 版本之间的不兼容程度如何?这些数字的含义是什么?

例如,从版本 2.8.7 到 3.0.1,我们可能会出现严重的不兼容问题。

但是,版本 2.7.1 和 2.7.2 或 3.0.6 和 3.0.7 有多不兼容?

How incompatible are rails versions with different version numbers? What's the meaning of these numbers?

For instance, from version 2.8.7 to 3.0.1, we may expect to have major incompatibility issues.

However, how incompatible would be versions 2.7.1 and 2.7.2 or 3.0.6 and 3.0.7?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

三寸金莲 2024-11-10 23:08:50

一般来说,数字变化越大,核心变化也越大。
因此,2.8.7 到 3.0.1 将是一个重大变化,因为我们从 Rails 2 转到 Rails 3(实际上是一个非常大的变化)。

另一方面,2.7.1 到 2.7.2 将进行一些小修复。

而且正如DHH自己所说,只要伟大的想法到来,Rails总是愿意100%改变它的核心。所以,你可以想象,从 2 到 3 或从 3 到 4 最有可能敲响巨大变化的钟声。

Generally speaking, the bigger the change on the numbers, the bigger the changes in core.
So, 2.8.7 to 3.0.1 would be a major change because we go from Rails 2 to Rails 3(and is actually a very big change for real).

On the other hand, 2.7.1 to 2.7.2 would be some minor fixes.

And as DHH himself said, Rails is always willing to change its core 100% as long as great ideas arrive. So, you can imagine that going for 2 to 3 or from 3 to 4 most probably rings the bell of vast changes.

挽清梦 2024-11-10 23:08:50

RubyGems 手册

图书馆以 3 种方式发生变化(嗯,更多
超过 3,但请保持专注!)。

  • 更改可能只是实施细节,对
    客户端软件。
  • 此更改可能会添加新功能,但这样做的方式应符合客户的要求
    以早期版本编写的软件
    仍然兼容。
  • 该更改可能会以这种方式更改库的公共接口
    那个旧软件不再是
    兼容。

RationalVersioningPolicy 提供
以下准则:

版本应由三个表示
非负整数,由
期间(例如3.1.4)。

第一个
整数是“主要”版本
数,第二个整数是
'''次要'''版本号,以及
第三个整数是 '''build'''
数量。

  • 类别 1 变更
    (实施细节)将增加
    内部版本号。

  • 类别 2 变更
    (向后兼容)将递增
    次版本号并重置
    内部版本号。

  • 类别 3 更改
    (不兼容)将增加
    主要版本号并重置次要版本号
    和构建编号。任何“公共”
    gem 的发布应该有
    不同的版本。通常这意味着
    增加构建号。这
    意味着开发人员可以生成构建
    整天为自己着想,但一旦
    当他/她公开发布信息时,
    版本必须更新。

就是这样。并不是太难。

另外。对此答案感兴趣的人可能也会对悲观版本约束感兴趣

In RubyGems Manual

Libraries change in 3 ways (well, more
than 3, but stay focused here!).

  • The change may be an implementation detail only and have no effect on the
    client software.
  • The change may add new features, but do so in a way that client
    software written to an earlier version
    is still compatible.
  • The change may change the public interface of the library in such a way
    that old software is no longer
    compatible.

The RationalVersioningPolicy provides
the following guidelines:

Versions shall be represented by three
non-negative integers, separated by
periods (e.g. 3.1.4).

The first
integers is the ’’’major’’’ version
number, the second integer is the
’’’minor’’’ version number, and the
third integer is the ’’’build’’’
number.

  • A category 1 change
    (implementation detail) will increment
    the build number.

  • A category 2 change
    (backwards compatible) will increment
    the minor version number and reset the
    build number.

  • A category 3 change
    (incompatible) will increment the
    major build number and reset the minor
    and build numbers. Any ’’public’’
    release of a gem should have a
    different version. Normally that means
    incrementing the build number. This
    means a developer can generate builds
    all day long for himself, but as soon
    as he/she makes a public release, the
    version must be updated.

That’s it. It’s not too difficult.

Additionaly. Who's interested in this answer may also be interested in the Pessimistic Version Constraint

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文