软件升级版本号迭代规范

一个良好的版本号的结构和改动规则,向用户传达了我们软件改动的影响级别。版本号标准依据Semantic Versioning 2 0 0,适用于APP,API,
一个良好的版本号的结构和改动规则,向用户传达了我们软件改动的影响级别。版本号标准依据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的次版本,让使用者平滑迁移到新版本。
您可能有感兴趣的文章
RAMOS (内存操作系统)

标准翻译:系统软件工程