给内部工具打tag时吵了一架：后端说升到1.2，前端说应该是1.2.0，运维问1.2.0-beta.2能不能上生产。版本号看着随意，其实有正式规范，写错了包管理器会拒绝发布。

SemVer三段式各代表什么

语义化版本2.0.0规定格式为主版本.次版本.修订号。主版本加一表示有不兼容改动，次版本加一表示新增向下兼容的功能，修订号加一表示修bug。1.4.2到2.0.0意味着调用方必须改代码。0.x.y视为开发期，API随时可能变，npm上大量包停在0开头就是这个原因。

预发布标识和构建号

1.2.0-alpha.1、1.2.0-beta.3、1.2.0-rc.1属于预发布版本，排序上永远小于同号的正式版。npm publish默认打latest标签，发beta要加--tag beta，否则用户npm i直接装到测试版。加号后面是构建元数据，如1.2.0+20241022，不参与比较。

另外三种常见体系

  • 四段号：Windows 10.0.19045.3803，第三段是build，第四段是revision，普通软件很少用。
  • 日期版本CalVer：Ubuntu 24.04、pip 24.1，按年月走，适合持续交付、不承诺兼容的服务。
  • 纯递增build：CI里直接用流水线号，如1024，只适合内部制品。

落地时的几条硬规则

版本号只增不减，回滚要发新号而不是复用旧号，否则镜像仓库会被覆盖。打tag前先执行git tag -a v1.2.0 -m 说明，tag名带v前缀是惯例。CHANGELOG按Keep a Changelog分组写Added、Changed、Fixed。

判断标准：对外提供SDK或API，老老实实SemVer；纯内部服务，CalVer加git短哈希更好追溯。最忌讳口头说小版本，实际改了接口字段名。