一个良好的版本号的结构和改动规则，向用户传达了我们软件改动的影响级别。版本号标准依据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的次版本，让使用者平滑迁移到新版本。
