问题描述

我的业务伙伴和我正在开发几个插件，我们想知道当有更新时是否有插件版本号的标准，即版本 1.0，版本 1.2，版本 1.2.3 等？

感谢任何建议。

最佳解决方案

不，没有标准。你甚至可以使用名字，罗马数字等等，但我不会推荐它。

大多数作者使用 Semantic Versioning：Major.Minor.Patch 。

这有几个缺点：

  • 用户害怕 「big changes」 。新版本的升级 (第一部分更改 (Major)) 通常会延迟，或者用户正在等待第一个 「service pack」(2.0.1) 。

  • 开发者有时不确定何时改变哪一部分。什么是专业？大的代码更改可能对用户体验影响不大。

  • 版本号的长度是不可预测的。 1.2.3 与 2.12.123 。不是很大的，但不是很理想。

在实践中，语义版本控制不是那种语义。

我更喜欢日期作为版本号：2012.11.19

  • 第一个数字的变化显然与程序中的 「big changes」 无关。

  • 没有 0 到底。决不。 🙂

  • 总是相同的长度 (除了每天有多个版本) 。

  • 与 version_compare()兼容 – 这可以被看作是一个标准。

推荐阅读：

这两个方案都有效。差异主要在于用户体验。

次佳解决方案

PHP 中版本号的标准如下：

主要点小数点修订

这些都是一个整数，独立于其余的。它不是十进制数。这很重要，因为 version_compare 如何工作。

MAJOR 是主要版本。您可以在对代码进行重大更改后更新此号码，例如彻底改变代码的工作方式。

MINOR 是次要版本。您可以在代码稍微更改后更新此号码，例如添加新功能。

REVISION 是修订号。在更改现有的次要版本 (例如修补程序) 后，您将更新此更新。

现在，再次版本是以点分隔的整数。所以，因为这样，版本 1.1 = 1.01; 这两个版本号是相同的，主要版本是 1，次要版本是 1 。

另一个例子，1.9 版本小于 1.10 版本; 小版本从九变为十。

因为 WordPress 使用 PHP 的 version_compare 函数，所以您必须按照这些方法进行版本编号。

请注意，WordPress 本身是一个次要的例外，因为核心从 2.9 到 3.0 。这是遗产，只是他们一直做编号的方式。它与 version_compare 功能兼容，但一般来说，如果没有重大的重写来证明主要版本的颠簸，应该从 2.9 到 2.10 。

参考文献

注：本文内容整合自 Google/Baidu/Bing 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。