🌚版本控制规范

type
status
date
slug
summary
tags
category
icon
password
Blocked by
Blocking
AI summary
 

版本号格式

版本号格式为：X.Y.Z（主版本号.次版本号.修订号）

版本号递增规则

  1. 主版本号 (X)
      • 当你做了不兼容的 API 修改时，递增主版本号
      • 例如：从 1.0.0 变成 2.0.0
  1. 次版本号 (Y)
      • 当你添加了向下兼容的新功能时，递增次版本号
      • 例如：从 1.0.0 变成 1.1.0
  1. 修订号 (Z)
      • 当你做了向下兼容的问题修正时，递增修订号
      • 例如：从 1.0.0 变成 1.0.1

重要规则

  1. 版本号从 0.1.0 开始
      • 开发初期使用 0.y.z 版本号
      • 此阶段属于开发初期，API 不稳定
  1. 1.0.0 版本定义
      • 当你的 API 稳定且可以投入生产环境时，应该发布 1.0.0 版本
      • 这表示你有了稳定的公共 API
  1. 预发布版本
      • 可以使用类似 1.0.0-alpha、1.0.0-beta.1、1.0.0-rc.1 这样的预发布版本号
      • 这表示这个版本还不够稳定

实际例子

假设你正在开发一个名为 "MyApp" 的应用：
  1. 初始开发版本：0.1.0
  1. 修复了一些 bug：0.1.1
  1. 添加新功能：0.2.0
  1. API 稳定，准备发布：1.0.0
  1. 修复生产环境 bug：1.0.1
  1. 添加新功能：1.1.0
  1. 进行不兼容的 API 修改：2.0.0

最佳实践

  1. 文档化
      • 清晰记录每个版本的变更
      • 说明 API 的变化
  1. 谨慎对待主版本号的更新
      • 破坏性更新会给用户带来升级负担
      • 尽可能保持向下兼容
  1. 预发布版本的使用
      • 重大更新前先发布 alpha/beta 版本
      • 收集用户反馈后再发布正式版
  1. 依赖管理
      • 在 package.json 等配置文件中明确指定依赖的版本范围
      • 例如："^1.2.3" 表示兼容 1.2.3 及以上的 1.x.x 版本

好处

  • 清晰地传达代码的变化程度
  • 更好地管理依赖关系
  • 避免"依赖地狱"
  • 使项目更容易维护和升级
需要注意的是，版本控制不仅仅是改变数字，更重要的是要理解这些数字背后的含义，并且负责任地进行版本发布。
Prev
如何构建一个短链系统
Next
kafka学习笔记
Loading...
Article List