版本号格式
版本号格式为：X.Y.Z（主版本号.次版本号.修订号）
版本号递增规则
- 主版本号 (X)
- 当你做了不兼容的 API 修改时，递增主版本号
- 例如：从 1.0.0 变成 2.0.0
- 次版本号 (Y)
- 当你添加了向下兼容的新功能时，递增次版本号
- 例如：从 1.0.0 变成 1.1.0
- 修订号 (Z)
- 当你做了向下兼容的问题修正时，递增修订号
- 例如：从 1.0.0 变成 1.0.1
重要规则
- 版本号从 0.1.0 开始
- 开发初期使用 0.y.z 版本号
- 此阶段属于开发初期，API 不稳定
- 1.0.0 版本定义
- 当你的 API 稳定且可以投入生产环境时，应该发布 1.0.0 版本
- 这表示你有了稳定的公共 API
- 预发布版本
- 可以使用类似 1.0.0-alpha、1.0.0-beta.1、1.0.0-rc.1 这样的预发布版本号
- 这表示这个版本还不够稳定
实际例子
假设你正在开发一个名为 “MyApp” 的应用：
- 初始开发版本：
0.1.0 - 修复了一些 bug：
0.1.1 - 添加新功能：
0.2.0 - API 稳定，准备发布：
1.0.0 - 修复生产环境 bug：
1.0.1 - 添加新功能：
1.1.0 - 进行不兼容的 API 修改：
2.0.0
最佳实践
- 文档化
- 清晰记录每个版本的变更
- 说明 API 的变化
- 谨慎对待主版本号的更新
- 破坏性更新会给用户带来升级负担
- 尽可能保持向下兼容
- 预发布版本的使用
- 重大更新前先发布 alpha/beta 版本
- 收集用户反馈后再发布正式版
- 依赖管理
- 在 package.json 等配置文件中明确指定依赖的版本范围
- 例如：
"^1.2.3"表示兼容 1.2.3 及以上的 1.x.x 版本
好处
- 清晰地传达代码的变化程度
- 更好地管理依赖关系
- 避免“依赖地狱”
- 使项目更容易维护和升级
需要注意的是，版本控制不仅仅是改变数字，更重要的是要理解这些数字背后的含义，并且负责任地进行版本发布。