软件升级版本号迭代规范-Semantic Versioning

一个良好的版本号的结构和改动规则，向用户传达了我们软件改动的影响级别。版本号标准依据Semantic Versioning 2.0.0，适用于APP，API，代码分支归档等。

Semantic Versioning 规范

• 版本号必须使用x.y.z格式，且均为正数。版本号的每个元素必须以正整数递增。
  • x 主版本号
  • y 次版本号
  • z 补丁版本号
  • 示例： 1.9.0 -》 1.10.0 -》1.11.0
• 一旦一个版本打包发布出去了，那么版本的内容就不能更改了。任何更改必须作为一个新的版本重新发布。
• 主版本为0（0.x.y）的版本作为开发初始阶段。任何东西都可能在任何时间修改，这个时候我们认为它是不稳定的。
• 1.0.0表明正式对外API公开版本的形成。从此版本号的递增取决于这个公开的API。
• 补丁版本号（x.y.z | x>0）,如果只有向后兼容的BUG被修复，补丁版本号必须递增。
• 次版本号（x.y.z | x>0）
  • 如果一个新的，向后兼容的功能被引入到公开API里，次版本号必须递增。
  • 如果公开API的任何功能被标记为“已弃用”，次版本号必须递增。
  • 如果大量新的功能被引入私有代码里面，次版本号可以递增。
  • 次版本号递增的时候，补丁号必须归零。
• 主版本号（x.y.z | x>0）任何向后不兼容的改动被引入到公开API中，主版本号必须递增。它的递增可以包含次版本和补丁级的改动。当它改动的时候，次版本号和补丁号必须归零。
• 一个预发布版本可以在补丁版本号后追加一个短线，以及一个用点分割标识来描述。例子: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7
• 版本优先级比较：“主版本号”，“次版本号”，“补丁号”，以数字方式比较，例子：1.0.0<2.0.0<3.0.0 
  • 如果有2个预发布版本号一致的时候，预发布版本比正常版本优先级低。例子：1.0.0-alpha < 1.0.0     

FAQ

在开发初始阶段，怎么处理0.y.z版本号？

一个简单的做法是将0.1.0作为第一个版本号，然后为随后的版本递增发布。

 

我怎么知道发布的版本是1.0.0？

当软件已经在生产环境上线了，那么我们通常定义为1.0.0。

如何处理即将弃用的功能？

弃用功能是软件向前开发中很正常的，通常也是必须的。当弃用API的时候应该做如下两件事：

• 更新文档让使用者知道这个事情。
• 发布一个新的，仍旧包含旧API的次版本，让使用者平滑迁移到新版本。