软件版本号命名

🎯 主要版本号规范

1. 语义化版本控制

格式: 主版本号.次版本号.修订号 (MAJOR.MINOR.PATCH)

版本号含义

• 主版本号 (MAJOR) ：当你做了不兼容的API修改
• 次版本号 (MINOR) ：当你做了向下兼容的功能性新增
• 修订号 (PATCH) ：当你做了向下兼容的问题修正

示例

1.0.0 → 1.0.1  (修复bug)
1.0.1 → 1.1.0  (新增功能)
1.1.0 → 2.0.0  (破坏性更新)

预发布版本标识

• Alpha: 1.0.0-alpha.1 (内部测试版本)
• Beta: 1.0.0-beta.2 (公开测试版本)

2. 日期版本号

格式: YYYY.MM.DD​ 或 YYYY.MM

示例

2024.01.15  (2024年1月15日发布)
2024.03     (2024年3月发布)

适用场景

• 定期发布的软件
• 内部工具和脚本
• 文档和配置文件

3. 序列版本号

格式: 简单的递增数字

示例

v1, v2, v3, v4...

适用场景

• 简单项目
• 内部工具
• 快速迭代的原型

4. 混合版本号

格式: 结合多种规范

示例

v1.2.3-beta.1
2024.1.0
v3.0.0-rc.2

🔍 详细规范说明

语义化版本控制详细规则

主版本号 (MAJOR)

• 触发变更条件：
• 移除或重命名API
• 改变默认行为
• 移除功能
• 改变数据格式
• 示例：

  1.0.0 → 2.0.0  (API不兼容)
  2.0.0 → 3.0.0  (架构重构)

次版本号 (MINOR)

• 触发变更条件：
• 新增功能
• 新增API
• 性能优化
• 新增配置选项
• 示例：

  1.0.0 → 1.1.0  (新增功能)
  1.1.0 → 1.2.0  (新增API)

修订号 (PATCH)

• 触发变更条件：
• 修复bug
• 安全补丁
• 文档更新
• 代码重构（不影响功能）
• 示例：

  1.0.0 → 1.0.1  (修复bug)
  1.0.1 → 1.0.2  (安全补丁)

📊 版本号比较规则

数字比较

1.0.0 < 1.0.1 < 1.1.0 < 2.0.0

预发布版本比较

1.0.0-alpha.1 < 1.0.0-alpha.2 < 1.0.0-beta.1 < 1.0.0

📝 变更日志

示例格式

## [1.2.0] - 2024-01-15

### Added
- 新增用户管理功能
- 添加数据导出功能

### Changed
- 优化登录流程
- 改进界面设计

### Fixed
- 修复数据同步问题
- 解决内存泄漏bug

### Removed
- 移除过时的API接口

变更类型

• Added: 新增功能
• Changed: 功能变更
• Deprecated: 废弃功能
• Removed: 移除功能
• Fixed: 问题修复
• Security: 安全更新

🌟 特殊版本号

1. 长期支持版本 (LTS)

Node.js 18.x LTS
Ubuntu 20.04 LTS

2. 里程碑版本

v1.0.0  (第一个稳定版本)
v2.0.0  (重大架构更新)
v10.0.0 (十周年纪念版本)

3. 特殊命名

Windows 95, 98, XP, Vista, 7, 8, 10, 11
macOS Big Sur, Monterey, Ventura

⚠️ 常见错误和注意事项

1. 版本号跳跃

❌ 错误: 1.0.0 → 1.0.5 (跳过了1.0.1-1.0.4)
✅ 正确: 1.0.0 → 1.0.1 → 1.0.2 → 1.0.3

2. 版本号重复

❌ 错误: 发布两个1.0.0版本
✅ 正确: 1.0.0 → 1.0.1

3. 版本号格式不一致

❌ 错误: v1.0.0, 1.0.1, v1.0.2
✅ 正确: v1.0.0, v1.0.1, v1.0.2

总结

从软件开发初始就做好版本号命名准备，确定好具体的命名规范。尽可能避免中途发生变更。