使用什么版本编号方案？答案

【问题标题】：What version numbering scheme to use?使用什么版本编号方案？
【发布时间】：2011-01-04 03:23:57
【问题描述】：

我正在寻找一个版本编号方案来表达变化的程度，尤其是兼容性。

Apache APR，例如，使用众所周知的版本编号方案

<major>.<minor>.<patch>
example: 4.5.11

Maven 提出了一个类似但更详细的架构：

<major>.<minor>.<patch>-<qualifier>-<build number>
example: 4.5.11-RC1-3732

Maven 版本控制方案在哪里定义？限定符和内部版本号是否有约定？使用 maven 但不遵循 Maven 版本方案可能是个坏主意...

您还知道哪些其他版本编号方案？您更喜欢哪种方案？为什么？

【问题讨论】：

会stackoverflow.com/questions/1889615/version-numbering-basics 帮忙吗？

标签： schema versioning maven

【解决方案1】：

我会推荐语义版本控制标准，Maven 版本控制系统似乎也遵循该标准。请检查，

http://semver.org/

简而言之，它是<major>.<minor>.<patch><anything_else>，您可以在其他任何部分添加其他规则，只要您觉得合适。例如。 -<qualifier>-<build_number>.

【讨论】：

Maven 的 -- 方案似乎与 semver.org 的推荐不完全匹配。 semver.org：“一个特殊的版本号可以通过附加一个任意字符串来表示紧跟补丁版本。字符串必须只包含字母数字加上破折号[0-9A-Za-z-]并且必须以字母字符 [A-Za-z] 开头。”
@deamon semver.org 可能在几年前对其进行了更改，但为了记录，它现在符合 maven 方案：“预发布版本可以通过附加连字符和一系列点分隔标识符来表示紧跟补丁版本。标识符必须仅包含 ASCII 字母数字和连字符 [0-9A-Za-z-]。标识符不得为空。数字标识符不得包含前导零。“
@kapep：格式仍然不完全兼容，因为来自 semver 的比较算法比 Maven 使用的要复杂得多。但如果你只坚持“-RC1”、“-RC2”或类似的，你应该没问题。

【解决方案2】：

这是current Maven version comparison algorithm 和discussion。只要版本只增长，并且除了内部版本号之外的所有字段都是手动更新的，你就很好。限定符的工作方式如下：如果一个是另一个的前缀，则越长越旧。否则，它们将按字母顺序进行比较。将它们用于预发布。

第二次使用语义版本来表达兼容性； major 用于非向后兼容的更改，minor 用于向后兼容的功能，patch 用于向后兼容的错误修复。记录它，以便您的库用户可以正确地表达对您的库的依赖关系。由于前缀的比较方式，您的快照是自动生成的，不需要递增，除非是发布后的第一个快照。

【讨论】：

【解决方案3】：

纯粹为了完整起见，我会提到old Apple standard for version numbers。这看起来像主要版本。 次要版本。 错误版本。舞台。 非发布版本。阶段是从集合 d（开发）、a（alpha）、b（beta）或 fc（我认为最终客户发货 - 或多或少与候选发布版本相同）。

stage 和 non-release revision 仅用于缺少适当版本的版本。

所以，第一个版本可能是 1.0.0。您可能已经发布了 1.0.1 的错误修复、1.1 的新版本（具有更多功能），以及 2.0 的重写或主要升级。如果您随后想向 2.0.1 工作，您可以从 2.0.1d1、2.0.1d2 开始，然后到 2.0.1d153 或任何您需要的东西，然后将 2.0.1a1 发送给 QA，在他们批准 2.0.1a37 之后，将 2.0.1b1 发送给一些愿意下注的人，然后在 2.0.1b9 在场上存活一周后，烧掉 2.0.1fc1 并开始获得签收。 2.0.1fc17够了，就变成2.0.1了，大喜过望。

这种格式已经足够标准化，因此有一个打包的二进制格式，以及库中用于进行比较的辅助例程。

【讨论】：

纯粹为了完整性（:-)），我想指出，恕我直言，每个阶段都需要单独构建（该方案暗示）不是一个好主意。至少最终 QA/测试的构建应该在生产中保持不变。任何所需的行为差异都应通过配置注入。参见例如Separate 'debug' and 'release' builds?.
@sleske 我认为这并不意味着每个阶段都有单独的构建。如果您处于 beta 测试阶段，您将在 dev 中创建 1.2.3b4，将其通过 CI，让 QA 批准，执行 UAT，然后将其推广给 beta 测试人员，一直使用相同的二进制文件。相反，这意味着在任何时候，您都知道构建可能会走多远 - 因此您知道何时提交它只会用于开发、发送给 beta 测试人员、发布等。在转换时存在一些重复，例如如果 1.2.3b10 通过 beta 测试，同样的代码可能会变成 1.2.3fc1，这并不理想。

【解决方案4】：

阅读了很多文章/问答/常见问题/书籍后，我开始思考 [MAJOR].[MINOR].[REV] 是最有用的版本控制架构描述项目版本之间的兼容性（版本控制模式用于开发人员，不适用于营销）。

MAJOR 更改向后不兼容，需要更改项目名称、文件路径、GUID 等。

MINOR 更改向后兼容。标记新品介绍功能。

REV 用于安全/错误修复。向后和向前兼容。

这个版本控制架构受到 libtool 版本控制语义和文章的启发：

http://www106.pair.com/rhp/parallel.html

注意：我还建议提供 build/date/custom/quality 作为附加信息（build 编号、构建日期、客户名称、发布质量）：

Hello 应用 v2.6.34，适用于 National bank，2011-05-03，beta，构建 23545

但此信息不是版本信息！

【讨论】：

【解决方案5】：

请注意，版本号方案（如 x.y.0 与 x.y）可能会受到外部因素的限制。

考虑announcement for Git 1.9 (Januaury 2014)：

一个候选版本 Git v1.9-rc2 现在可以在通常的地方进行测试。

我听说各种第三方工具不喜欢两位数的版本号（例如“Git 2.0”）开始左右吐槽当用户安装 v1.9-rc1.
虽然很容易因为他们草率的假设而嘲笑他们，但我也很实际，不介意调用即将发布的 v1.9.0 版本来帮助他们。

如果我们走那条路（我现在倾向于走那条路），版本控制方案将是：

下一个候选版本将是v1.9.0-rc3，而不是v1.9-rc3；

v1.9.0 的第一个维护版本将是 v1.9.1（第 N 个是 v1.9.N）；和

v1.9.0 之后的功能版本将是 v1.10.0 或 v2.0.0，具体取决于我们看到的功能跳跃有多大。

【讨论】：