水经注语义化版本控制规范1.2.0版
为了更好的对产品进行版本管理，我们曾基于业界的一些权威参考资料，梳理过两版水经注产品的版本控制规范。
但随着多个平台的产品研发，以及产品在各平台的更新发布，再结合我们的实际情况，现在对版本控制规范进行一次升级调整。
版本号格式
（1）标准的版本号必须采用 X.Y.Z 的格式；
（2）其中 X、Y 和 Z 为非负的整数，且禁止在数字前方补零；
（3）X 是主版本号、Y 是次版本号、而 Z 为修订号；
（4）每个元素必须以数值来递增。例如：1.9.1 -> 1.10.0 -> 1.11.0；
（5）标记版本号的软件发行后，禁止改变该版本软件的内容，任何修改都必须以新版本发行。
主版本号
(1)主版本号 X（X.y.z | X > 0）必须在有任何不兼容的修改被加入时递增；
(2)其中可以包括次版本号及修订级别的改变，也就是说修改的问题比较大时可以改变；
(3)每当主版本号递增时，次版本号和修订号必须（MUST）归零。
次版本号
（1）次版本号 Y（x.Y.z | x > 0）必须在有向下兼容的新功能出现时递增；
（2）在任何功能被标记为弃用时也必须递增；
（3）也可以在内部程序有大量新功能或改进被加入时递增；
（4）其中可以包括修订级别的改变，也就是说如果修订的问题比较大时可以改变；
（5）每当次版本号递增时，修订号必须归零。
修订号
（1）修订号 Z（x.y.Z | x > 0）必须在只做了向下兼容的修正时才递增；
（2）这里的修正指的是针对不正确结果而进行的内部修改；
（3）修订号需要在release版本的基础上，发现还存在问题，才会产生修订版本；
（4）如果修订版本的功能比较复杂，有待用户反馈，则需要先发行beta版本，如：1.5.1-beta；
（5）如果修订版本的功能比较简单，经测试充分并能确保质量，则可以直接发修订版本的release版本，跳过beta版和rc版。
先行版本号
（1）先行版本号及版本编译信息加到“主版本号.次版本号.修订号”的后面，作为延伸；
（2）先行版本号可以（MAY）被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符来修饰；
（3）标识符必须（MUST）由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止（MUST NOT）留白；
（4）数字型的标识符禁止（MUST NOT）在前方补零；
（5）先行版的优先级低于相关联的标准版本；
（6）被标上先行版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求。
例如alpha版本先行版本号：1.0.0-alpha.1、1.0.0-alpha.2、1.0.0-alpha.3
例如beta版先行版本号：5.0.0-beta.1、5.0.0-beta.2、5.0.0-beta.3
内测版
（1）内测版本号可以被标注在修订版之后，先加上一个连接号再加上一连串以点分隔的标识符来修饰；
（2）标识符必须由 ASCII 字母数字和连接号 [0-9A-Za-z-] 组成，且禁止留白；
（3）数字型的标识符禁止在前方补零；
（4）内测版的优先级低于相关联的标准版本;
（5）内测版用alpha标识，被标上内测版本号则表示这个版本并非稳定而且可能无法满足预期的兼容性需求;
例如：1.0.0-alpha、1.2.0-alpha.1、5.1.0-alpha.12
（6）内测版本升级基于数字递增;
例如：5.0.0-alpha.1、5.0.0-alpha.2、5.0.0-alpha.3、5.0.0-alpha.4
（7）内测版仅供公司内部人员测试用，不向外部用户提供。
公测版
（1）公测版用beta标识，被标记为公测版则表示该版本的功能和稳定性还有待修订的可能性；
（2）公测版主版本或次版本升级后的第一个发布版本，因此修订号需要归零。例如：1.0.0-beta、1.2.0-beta、5.0.0-beta
（3）当需要修复问题但不新增功能时，递增先行版本号。例如：5.0.0-beta、5.0.0-beta.2、5.0.0-beta.3
RC版
（1）RC 版全称是 Release Candidate，指发行候选版本；
（2）其中 Release 是发行、发布的意思，Candidate 是候选人的意思，用在软件或者操作系统上就是候选版本。
正式版
（1）当beta版（或rc版）经过一定时间段的用户公测修订后，将去掉beta标识（或rc标识）成为正式版；
（2）正式版意味着已经过用户的使用检验，理论上将不会存在比较大的问题，且运行稳定。
10
编译信息
（1）版本编译信息可以被标注在版本末尾，先加上一个短横线再加上编译信息（build号）例如：1.0.0-alpha.1-build16063、1.0.0-alpha.1-build16064
平台信息
（1）平台信息主要用于区别操作系统平台；
（2）平台信息主要分：x86、x64和linux等。
水经注语义化版本控制规范
基于上述语义化版本控制规范，我们整理出了适合水经注产品的语义化版本控制规则，并在相应的开发阶段作了举例说明。
语义化版本控制规范示例
苹果IOS版本控制
由于苹果商店中上传beta版与正式版是分开的，而我们产品更新迭代的频率又比较高。
因此，在同一个次版本号下的多个beta版、rc版或修订版，都采取修订号自然增长的方式进行发布。
但我们在开发过程中，仍然按本文所规定的语义化版本规范，并与发布版本进行一一对应管理。
苹果IOS版本管理示例
写在最后
通过语义化版本规划，我们可以透过修改相应的版本号来向用户说明产品的修改。
当然，每个产品的实际情况不同，比如更新迭代很快的产品就会跳过rc版本，而beta版本的周期也会比较短（甚至也会跳过）。
我们水经注产品的版本控制规范，虽然参考自权威资料，但也根据我们的实际情况进行了调整。
因此，我们在制定自己的产品版本控制规范时，一定不能生搬硬套，但也要遵循最基本的版本控制规则。
最后，本文仅供大家参考，并欢迎提出不同的意见和建议，让我们共同进步！