使用 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

配置解析：

睿拓智能网站系统-网上商城

睿拓智能网站系统-网上商城1.0免费版软件大小:5M运行环境：asp+access本版本是永州睿拓信息专为电子商务入门级用户开发的网上电子商城系统，拥有产品发布，新闻发布，在线下单等全部功能，并且正式商用用户可在线提供多个模板更换，可实现一般网店交易所有功能，是中小企业和个人开展个人独立电子商务商城最佳的选择，以下为详细功能介绍：1.最新产品-提供最新产品发布管理修改，和最新产品订单查看2.推荐产

下载

• [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 命令将其降级或