定义一个有意义的版本 ，让你的软件版本生动起来

在GJB5000/CMMI中，有一个配置管理过程域，它的第一条专用实践就是“标识配置项”，要求给每个受控的配置项赋予一个唯一的标识，而且对于同一个配置项来说，在它的生命周期内还有不同版本之说，配置项的每一个版本对应的是它的一种状态，就像类和实例对象那样。

所以，配置管理除了要制订配置项标识规范外，还要制订版本标识方法。

常用的版本标识方法简单的有VX.Y、VX.Y.Z等。其中V表示版本，X为主版本 表示软件有重大功能变更，Y为次版本 表示软件有较小的改进，Z一般表示修复次数。

复杂的版本标识方法由四部分组成，第一部分为主版本 ，第二部分为子版本 ，第三部分为软件开发阶段版本 ，第四部分为日期版本 加希腊字母版本 ，希腊字母版本 共有5种，分别为：base、alpha、beta、RC、release。例如：1.1.1.051021_beta。

这些方法肯定能满足每个配置项具有唯一标识的要求，甚至也能够区分出同一配置项的不同状态，但是，这样的版本标识对你的帮助不会太大。因为当你看到一个V1.1的软件版本，你只知道它发生了变化，但它发生了什么变化，它适用于何种应用场景，你依然一无所知。如果你想知道这些内容，你不得不去查看配置状态 告。

那么，我们能不能赋予软件版本一个更有意义的标识，让人一眼看去就知道它是个什么状态呢？

一些实施GJB5000的组织的一些做法就值得提倡。比如，将主版本 和项目的研制阶段绑定起来，0表示方案阶段，1表示工程研制阶段，2表示定型阶段。这样至少让人一看就知道这个软件是哪个研制阶段的版本。

再比如，用版本 区分不同的应用场景。软件在完成内部交付之后，还会参加各种外场试验，而这时可能会出现不同版本的软件要同时参加多个试验场景，那么，你可以在版本 中增加一段表示这种场景的，00代表参加试验前原始版本，AA代表试验简称。这样你一看到V1.1.00，应知道是工程研制阶段，有过一次修改，没有参加任何试验的版本；一看到V1.1.AA，就表示该软件是工程研制阶段，有过一次修改，参加AA试验的版本。

以上只是举了两个简单的例子，是想说明一下让软件版本 不仅起到区分软件不同状态的基本功能之外，让它的标识更鲜明更有意义。而这个意义取决于组织实际面临的情况，每个组织可以选取对自己有意义的标识。

另外，有意义的版本 ，不仅考虑对开发人员的意义，还要考虑对管理部门、生产部门甚至用户所代表的意义。

反正，我们管理软件版本需要有版本标识方法，那么为什么不让它更有意义呢？

版本标识很容易，区分状态保唯一

如能结合实际来，标识更加有意义

参考文献：闲话IT项目管理，曹亚波，电子工业出版 。