使用 Bumpversion 实现可选的开发版本后缀管理

引言：Bumpversion 与版本管理

在软件开发中，版本管理是至关重要的一环。bumpversion 是一个功能强大的命令行工具，它能够自动化地管理项目版本号，包括更新版本字符串、修改文件内容，并支持 Git 提交和标签创建。在许多开发场景下，我们不仅需要管理主版本（如 major.minor.patch），还需要引入可选的预发布后缀，例如 dev、alpha、beta 或 rc，以区分开发、测试或候选发布版本。本文将聚焦于如何配置 bumpversion 以优雅地处理这种可选的 dev 版本后缀。

挑战：单值部分的限制

当尝试为 bumpversion 配置一个可选的 dev 版本后缀时，一个常见的陷阱是，如果 dev 版本部分在 [bumpversion:part:dev] 中只定义了一个值（例如 dev），那么在尝试执行 bumpversion dev 命令时，系统会抛出 ValueError: The part has already the maximum value among ['dev'] and cannot be bumped. 错误。

以下是导致此问题的典型配置片段：

[bumpversion:part:dev]
values =
    dev

出现此错误的原因在于，bumpversion 期望一个版本部分能够从一个状态“提升”到另一个状态。如果 values 列表中只有一个值，bumpversion 会认为该部分已经处于其最大值状态，因此无法再进行“提升”操作。

解决方案：引入初始空状态

解决这个问题的关键在于为 dev 版本部分提供一个“初始”或“空”的状态。通过在 [bumpversion:part:dev] 的 values 列表中添加一个空字符串 "" 作为第一个值，我们为 bumpversion 提供了一个明确的起点，使其能够从“无开发版本后缀”的状态提升到“有开发版本后缀”的状态。

修正后的配置片段如下：

[bumpversion:part:dev]
values =
    ""
    dev

当 bumpversion 解析一个不包含 dev 后缀的版本（例如 1.5.3）时，它会将 dev 部分视为处于 values 列表中的第一个状态，即 ""。此时，执行 bumpversion dev 命令，dev 部分就可以从 "" 提升到 dev，从而成功添加 dev 后缀。

完整配置示例与解析

为了实现可选的 dev-{build} 版本后缀，我们需要一个完整的 .bumpversion.cfg 配置。下面是一个示例，它支持 major.minor.patch 和 major.minor.patch-dev-build 两种版本格式：

[bumpversion]
current_version = 1.5.3
parse = (?P\d+)\.(?P\d+)\.(?P\d+)(-(?P.*)-(?P\d+))?
serialize =
    {major}.{minor}.{patch}-{dev}-{build}
    {major}.{minor}.{patch}

[bumpversion:part:dev]
values =
    ""
    dev

[bumpversion:part:build]
first_value = 1

配置解析：

• [bumpversion] 主配置：

  • current_version = 1.5.3：指定当前项目的版本号。
  • parse = (?P\d+)\.(?P\d+)\.(?P\d+)(-(?P.*)-(?P\d+))?：
    • 这是一个正则表达式，用于解析版本字符串。
    • (P\d+)\.(?P\d+)\.(?P\d+)：匹配主版本号、次版本号和修订版本号。
    • (-(P.*)-(?P\d+))?：这是一个可选的捕获组，用 ? 表示整个后缀部分是可选的。
      • -(?P.*)：捕获 dev 字符串（或其他任意内容），并将其命名为 dev 部分。
      • -(?P\d+)：捕获构建号，并将其命名为 build 部分。
    • 这个 parse 规则能够正确解析 1.5.3 (此时 dev 和 build 部分为 None) 和 1.5.3-dev-1 (此时 dev 为 dev，build 为 1) 两种格式。
  • serialize =：定义如何将解析出的版本部分重新组合成版本字符串。
    • {major}.{minor}.{patch}-{dev}-{build}：这是第一个序列化模式，用于包含 dev 和 build 部分的版本。
    • {major}.{minor}.{patch}：这是第二个序列化模式，用于不包含 dev 和 build 部分的版本。
    • bumpversion 会按顺序尝试这些模式，并使用第一个能够成功序列化所有当前存在的版本部分的模式。

• [bumpversion:part:dev]：

  • values = "" \n dev：定义 dev 部分可能的值。
    • ""：代表没有 dev 后缀的初始状态。
    • dev：代表带有 dev 后缀的状态。
  • 当 dev 部分从 "" 提升到 dev 时，bumpversion 会使用第一个 serialize 模式。

• [bumpversion:part:build]：

  • first_value = 1：定义 build 部分的起始值。当 dev 部分被首次引入时，build 部分将从 1 开始。

操作示例

假设 current_version = 1.5.3：

1. 添加 dev 后缀并初始化 build 号：

   bumpversion dev

   登录后复制

   执行后，current_version 将变为 1.5.3-dev-1。

2. 在 dev 版本上提升 patch 版本： 假设 current_version = 1.5.3-dev-1：

   bumpversion patch

   登录后复制

   执行后，current_version 将变为 1.5.4-dev-1。

3. 在 dev 版本上提升 build 号： 假设 current_version = 1.5.3-dev-1：

   bumpversion build

   登录后复制

   执行后，current_version 将变为 1.5.3-dev-2。

注意事项与局限性

• 非循环性： bumpversion 的版本部分提升通常是非循环的。这意味着，一旦 dev 部分从 "" 提升到 dev，您无法通过再次执行 bumpversion dev 命令将其降级或

以上就是使用 Bumpversion 实现可选的开发版本后缀管理的详细内容，更多请关注php中文网其它相关文章！