使用语义版本控制时如何避免 master 和 bugfix 分支之间的版本号冲突答案

【问题标题】：How to avoid version number conflict between master and bugfix branch when using semantic versioning使用语义版本控制时如何避免 master 和 bugfix 分支之间的版本号冲突
【发布时间】：2023-01-27 23:35:12
【问题描述】：

到目前为止，遵循语义版本控制的 git 中的主分支已在其生命周期中发布了以下版本。

1.0.0 -> 1.0.1 -> 1.1.0 -> 1.2.0

一个名为 hotfix\1.0.0 的修补程序分支被截断，用于错误修复/兼容扩展，这将需要发布为 1.0.1 或 1.1.0 的版本。但是这两个版本号都已经在大师级发布了。避免与版本发生此类冲突的最佳策略是什么。

【问题讨论】：

你有不同的选择：1.将 patch 部分专用于修补程序2.使用 - 获取修补程序版本信息。 1.0.0-hf1、1.0.0-hf2 或任何其他格式。3.使用 + 获取构建信息。
选项 1 意味着主版本上的错误修复将不会在语义版本中得到适当的满足。它被视为新功能添加。选项 2 使用预发布标识符。但是将其设置为 1.0.0-hf1 将意味着 1.0.0-hf1 被视为低于 1.0.0 的版本，但实际上恰恰相反。

标签： release versioning semantic-versioning hotfix

【解决方案1】：

Semantic Versioning 2.0.0开头有这部分：

给定版本号 MAJOR.MINOR.PATCH，递增：

进行不兼容的 API 更改时的主要版本

以向后兼容的方式添加功能时的次要版本

修复向后兼容的错误时的 PATCH 版本
因此，修补程序将进入补丁版本，因为它不添加任何功能但修复了一个错误。

如果你想避免这样的情况，你有一个补丁计划，并想在该补丁发布之前发布一个修补程序，而你不能或不想更改计划发布的版本，你可以为补丁版本号添加更多的语义含义本身。

例如，您可以说任何常规补丁版本都是偶数，而修补程序补丁发布版本是奇数。

因此，如果您在1.0.0并且计划1.0.2，那么您可以拥有1.0.1-hotfix.1

由于 PATCH 表示错误修复并且不得破坏兼容性（除非用户依赖错误 - 这不应该是你的问题）库的用户应该始终更新到最新的 PATCH 版本。因此，用户永远不会需要 0.0.1 hotfix，以防万一。 0.0.4 已经可用，错误已经在0.0.4 中修复，或者0.0.4 也必须修复，导致新的补丁版本比0.0.4 更新。

GitHub 上也有关于该主题的讨论：semver#241

【讨论】：