版本号的管理 #

前言 #

在现代软件开发过程中，相较于“重复造轮子”，开发者往往会利用一些已有的组件（如库、程序、多媒体文件）进行开发。程序开发者根据特定版本的组件来设计自己的软件。这种方式使得代码重复利用，减少了开发的工作量，降低了开发门槛。但是该软件要正确运行，必须安装了指定版本的某些组件。

操作系统中由于软件之间的依赖性不能被满足而引发的问题称为依赖地狱。依赖地狱主要有以下表现：

依赖过多：一个软件包可能依赖于众多的库，因此安装一个软件包的同时要安装几个甚至几十个库包。
多重依赖：指从所需软件包到最底层软件包之间的层级数过多。这会导致依赖性解析过于复杂，并且容易产生依赖冲突和环形依赖。
依赖冲突：即两个软件包无法共存的情况。除两个软件包包含内容直接冲突外，也可能因为其依赖的低层软件包互相冲突。因此，两个看似毫无关联的软件包也可能因为依赖性冲突而无法安装。
依赖循环：即依赖性关系形成一个闭合环路，最终导致：在安装 A 软件包之前，必须要安装 A、B、C、D 软件包，然而这是不可能的。

主版本号 . 子版本号 [. 修正版本号 build- [编译版本号 ]]
示例：

主版本号 . 子版本号 [ 修正版本号 [. 编译版本号 ]]
示例：

项目初版，版本号为 1.0 或 1.00;
当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1;
当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0，因而可以被忽略掉 ;
当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1;
编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，并不进行人为控制 ;
还可以在版本号后面加入 Alpha,Beta,Gamma,Current,RC (Release Candidate),Release,Stable 等后缀，在这些后缀后面还可以加入 1 位数字的版本号;

对于用户来说，如果某个软件的主版本号进行了升级，用户还想继续那个软件，则发行软件的公司一般要对用户收取升级费用; 而如果子版本号或修正版本号发生了升级，一般来说是免费的.

主版本号.子版本号[.编译版本号[.修正版本号]]

主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。
所有定义的部分都必须是大于或等于 0 的整数。
应根据下面的约定使用这些部分：
- Major：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。
- Minor：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。
- Build：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。
- Revision：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序 (Hotfix) 更新。

注：严格来说上面这些并不是版本号，一般在版本号中使用的只有五个，用来表示软件处于那个开发阶段

非紧急情况：首先由测试人员测试并提交 Bug，其次开发人员会尽量在当天修复 Bug 并在第二天发布该版本的 alpha 版，然后由测试人员测试验证关闭 Bug 之后在第三天会发布该版本的 beta 版。
紧急情况：如果 Bug 比较紧急可跳过一般流程，由开发人员尽快修复 Bug，测试确认之后直接发布该版本的 beta 版。

项目名称 + 文件的描述 + 当前软件的版本号 + _阶段标识 注：同一版本同一阶段的文件修改过两次以上，则在阶段标识后面加以数字标识，每次修改数字加1。

示例：