语义版本控制指南
-
语义版本控制（Semantic Versioning，简称 SemVer）是一种用于版本控制的规则和约定，它帮助开发者清晰地表达软件版本的变化和兼容性。通过遵循 SemVer，开发者和用户可以更容易地理解版本之间的关系，从而避免不必要的错误和混乱。
在红石中继站发布作资源时，除了发布资源介绍以外，您还需要发布版本来发布您的资源文件。在发布版本时，您将会用到语义版本控制。
什么是语义版本控制？
语义版本由三部分组成，格式如下：
MAJOR.MINOR.PATCH- MAJOR（主版本号）：当您做了不兼容的 API 修改时，增加主版本号。
- MINOR（次版本号）：当您在不破坏向后兼容性的前提下增加了功能时，增加次版本号。
- PATCH（修订号）：当您做了向后兼容的问题修正时，增加修订号。
例如，版本
1.7.10表示主版本号是 1，次版本号是 7，修订号是 10。附加标识符
语义版本也可以带有附加标识符（如预发布版本或构建元数据）。它们的格式为：
MAJOR.MINOR.PATCH-PRERELEASE+BUILD- PRERELEASE（预发布版本）：表示版本还在开发中，不稳定，通常用于测试。可以是
alpha、beta或自定义标签。 - BUILD（构建元数据）：通常是版本构建的编号或标识，便于区分不同的构建。
例如，
1.4.2-alpha.1表示一个处于 alpha 测试阶段的预发布版本，而1.4.2+build5678则包含了构建元数据。版本号变化的规则
根据 SemVer 规范，版本号的变化必须遵循以下规则：
主版本号（MAJOR）
当您对软件做了不兼容的 API 改动时，应该增加主版本号。这通常意味着：
- 现有的功能或 API 被移除或改变，导致之前的调用或接口不能再正常工作。
- 用户需要修改其使用的软件代码以适配新版本。
示例：
- 从
1.0.0升级到2.0.0，意味着 API 发生了不兼容的变化，可能会导致现有应用程序出现故障或错误。
次版本号（MINOR）
当您在不破坏向后兼容性的情况下，向软件中添加了新的功能时，应该增加次版本号。这意味着：
- 新功能是可选的，不会影响现有的功能。
- 现有的 API 和功能保持向后兼容。
示例：
- 从
1.4.0升级到1.5.0，意味着增加了新特性或功能，但不影响旧的功能。
修订号（PATCH）
当您做了向后兼容的错误修复时，应该增加修订号。这通常意味着：
- 修复了程序中的 bug 或问题，但没有引入任何新特性或不兼容的更改。
- 该版本主要是为了提升稳定性或修复已知问题。
示例：
- 从
1.4.1升级到1.4.2，意味着修复了 bug 或进行了小范围的性能优化，但没有改变功能。
预发布版本（Pre-release）
预发布版本通常用于开发或测试阶段，版本标识符以连字符
-分隔。例如：1.4.0-alpha.1alpha、beta、rc（候选发布）等标识符代表不同的阶段。- 预发布版本不能代表稳定版本，因此可以包含尚未完成的特性或 API 改动。
示例：
1.4.0-beta.1表示这是一个 beta 测试版本，功能已经接近完成，但可能存在问题。1.4.0-rc.1表示发布候选版本，几乎没有问题，正在进行最后的验证。
构建元数据（Build Metadata）
构建元数据用于标识构建过程中的信息，通常不会影响版本的兼容性。它以加号
+分隔，并且通常用于记录构建的详细信息，如构建编号或日期。示例：
1.4.0+build5678表示这是版本1.4.0的某个特定构建，build5678可能是一个构建编号。
版本号的实际应用
如何更新版本号？
根据软件的改动类型，选择正确的版本号更新规则：
- 添加新功能：增加次版本号。
- 修复问题：增加修订号。
- 破坏兼容性更改：增加主版本号。
注意： 增加主版本号时，旧版本的用户可能需要修改代码，因此需要提前通知他们。
版本号的顺序
版本号应按以下顺序递增：
MAJOR > MINOR > PATCH例如：
1.0.0→1.1.0→1.2.0→2.0.0→2.1.0→2.1.1。