前言
在研发日常工作中，常常会使用到别人的代码包，绝大部分软件也会有版本号控制。
绝大多数情况下，软件的版本号定义遵循semver语义，是X.Y.Z这种格式的版本号，这个标准是github组织起草的，是个事实上的行业标准。
版本号规则
主要规则
X 代表主版本号
也可以称为major号。当做了破坏性的、颠覆性的改动，已无法与低版本兼容时，更新主版本号。每当主版本号递增时，次版本号和修订号必须归零。
一般从0开始，0作为主版本号，意味着此版本为非正式发布的版本，所有功能均处于测试中，会有较为频繁的功能更新与改动。
当主版本号从0升级为1时，意味着此版本作为正式发布的稳定版本。
Y 代表次版本号
也可以称为feature号。当做了向下兼容的功能性更新时，升级次版本号。每当次版本号递增时，修订号必须归零。
Z 代表修订号
也可以成为bugfix号。当做了向下兼容的小问题修正时， 升级修订号。
先行版本
先行版本号的格式一般为 X.Y.Z-<Tag>.N，如 2.13.5-beta.3。
先行版本类型有以下三种：
alpha
预览版，或者叫内部测试版。一般不会外部发布，仅供内部测试人员测试，会有很多bug，一般开发团队自测完毕后发布。
beta
测试版，或者叫公开测试版，是在经历过alpha版本测试后发布的版本，相对bug较少。此版本经过一段时间公开测试后，进入下一阶段。
rc(release candidate)
发布候选版本，是可能成为最终产品的候选版本，如果未出现问题则发布成为正式版本。
版本号升级场景演示
我现在开发一个新的软件 并发布非正式版本 ，起始版本号为0.1.0。此版本号中的所有功能均作为首个发布版本的内容。
一段时间后，我开发了一个新功能，这时候升级feature版本号，发布版本为0.2.0。
经历过一段时间更新后，现在软件版本号来到了0.4.0，有用户在使用时发现了bug。
我现在修复了这个bug，发布版本为0.4.1。
又经历过一段时间的功能新增与bug修复，现在版本号来到了0.10.5
我认为现阶段软件已经可以作为正式版本发布，升级主版本号，发布新版本1.0.0。
在此版本之后，如果不升级主版本号，则所有功能更新与bug修复均需要考虑向下兼容，经历过一段时间的更新后，版本号来到了1.4.10。
此时，开发团队发现，现有的代码架构已无法支撑新的功能，或不希望再向下兼容过旧的版本。
此时发布新的破坏性版本更新，版本号更新为2.0.0，之后以此类推。
先行版本升级场景示意
现在正在版本1.4.10，开发团队已基本完成2.0.0的开发工作。
现在发布先行预览版进行测试，首先发布2.0.0-alpha.0，作为首个先行预览版本发布，以供内部测试人员测试。
在先行预览版版本中，开发团队仍可进行feature 与bugfix更新，所有改动均会作为新版本发布时的更新内容。
经历过一段时间测试，现在内部人员测试完毕，版本号来到了2.0.0-alpha.5。
现在发布公开测试版本2.0.0-beta.0，供其他用户使用与测试，使用此版本的用户应当了解此版本可能会存在的问题的现状。
在公开测试版本中，开发团队一般仅进行bugfix 更新，不再新增功能。
经历过一段时间测试，参与测试的用户暂时没有发现更多问题，版本号来到了2.0.0-beta.2。
一般经历过公开测试版本后，便可以正式发布了。
但在更严格、更规范的测试流程与发布流程中，还需进行rc发布后选版本的发布流程。这个过程的版本号更新与前两个流程同理，不再赘述。
写在最后
以上版本号控制仅为理想情况的版本号规范方案。
相对来说，github上的大部分开源软件、组件库、函数库、代码框架，会更加遵守上面这套版本号规范，而实际的软件、游戏的版本号可能由更多不同的因素决定。
例如有的软件会以软件发布年份作为主版本号，每年发布一个新版本，主版本之间并没有严格意义上的兼容性区别，不兼容的版本一般厂家会强制用户更新版本。
在线游戏也常常是一年发布一个新的主版本，以游戏运营的版本周期更新次版本号，而热更新和bug修复更新的修订版本号，用户一般不感知。
在线游戏版本的最大特点是，在线游戏一般均会强制升级所有版本号，用户无法使用旧版本使用。
单机游戏则情况更加复杂，有的是版本之间存档互不兼容，有的则相近版本之间互相兼容，但一般旧版本支持升级到新版本，但不支持新版本回到旧版本。