24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
|
SemVer 2，即 “Semantic Versioning 2.0.0”，是一种版本控制策略，用于管理应用程序、库和API的版本号。它是一种约定俗成的规范，通过版本号来清晰地表达软件变更的意义。
|
|||
|
|
|
|||
|
|
根据SemVer 2.0.0，版本号被定义为 `MAJOR.MINOR.PATCH`，具体含义如下：
|
|||
|
|
|
|||
|
|
1. **MAJOR（主版本号）**：当你做了不兼容的 API 修改；
|
|||
|
|
2. **MINOR（次版本号）**：当你做了向下兼容的功能性新增；
|
|||
|
|
3. **PATCH（修订号）**：当你做了向下兼容的问题修正。
|
|||
|
|
|
|||
|
|
另外，还包括一些额外的标签用于标示预发布版本和构建元数据，这部分通常以 `-` 或 `+` 连接到版本号的后面：
|
|||
|
|
|
|||
|
|
- **预发布版本标签**（如 `1.0.0-alpha`、`1.0.0-beta`）：用于在开发过程中标示不稳定的版本，这些版本不一定是完全的。
|
|||
|
|
- **构建元数据**（如 `1.0.0+20130313144700`）：用于标示构建的特定信息，通常用于区分不同的构建，而不影响版本排序。
|
|||
|
|
|
|||
|
|
一个完整的版本号实例可能是： `1.4.7-alpha.1+exp.sha.5114f85`。
|
|||
|
|
|
|||
|
|
### 具体规则和示例：
|
|||
|
|
|
|||
|
|
- **初始开发阶段**：0.Y.Z 版本号，当软件还在开发初期阶段，不稳定，不应保证API稳定性。
|
|||
|
|
- **发布1.0.0版本后**：
|
|||
|
|
- **MAJOR版本变更**：`1.0.0` -> `2.0.0`，表示不兼容API的重大修改。
|
|||
|
|
- **MINOR版本变更**：`1.1.0` -> `1.2.0`，表示新增了功能，但是保持向后兼容。
|
|||
|
|
- **PATCH版本变更**：`1.1.1` -> `1.1.2`，表示修复了错误，保持向后兼容。
|
|||
|
|
|
|||
|
|
通过采用 SemVer 规范，开发者和用户可以更清楚地理解每个发布版本的变更范围和潜在影响，有助于版本管理和依赖管理。
|