软件版本号执行背后的故事

序：

近日管理中心的同事C询问关于软件版本号管理的事情，定义公司软件版本号的规则，写入CMMi执行的条例中。C同事定义的软件版本号的三段规则，记为major.minor.(revision)，第一段主版本号major表达主要的软件版本，第二段是次版本号minor表达软件的升级补丁，第三段是可选段，用修订号revision用于表达软件的紧急修复。对于C定义的软件版本号，我赞成，也赞成不要把build号做为软件版本号之一，因为目前我们同事的软件开发水平、管理水平还没有能做到Daily Build。

关于软件版本号的定义，很多同事即使没有软件编号的经验，但是或多或少在日常工作中都接触过软件，也会注意到使用到的软件的版本号。或者在学校上课的时候，老师也一般会讲到软件版本号。但是我在实践的工作中，发现并不是很多同事能够理解软件版本号，并且将软件版本号和配置管理结合应用到位。

案例：

上年12月底抽查了某项目的系统上线过程，发现了项目组竟然没用使用配置库，而是从各位同事的机器中获取不同的代码。当时着实让我吃一惊，原来同事在业主的工作环境进行现场开发，由于工作环境搬迁，与公司的代码库连接由于公网配置原因，时断时续。因此，他们当时无法从配置库中Check In/Out出版本，上线过程又有Bug，又要修复，管理过程之苦，可想而知！

在通过后续痛苦上线后，经过了近三个星期的稳定后，我要求项目组在一月份春节前两个星期再上一次线，要求从SVN拿出最新的版本上线，否则以后我们哪敢相信代码库的代码就是在系统运行的代码。春节回来后，又抽查到项目组的工作，项目组确实又是按计划在农历年前做到SVN代码库上线的目标，保证了SVN版本和系统运行环境的一致。

我稍稍放心了，但是职业习惯让我多问了一句：“最近是否有紧急修复啊？”

同事LL回答说：“有啊”

我又接着问：“那么紧急修复也是从SVN中Check Out上线吗？”

同事LL差异地看着我：“我们还在进行新版本的开发，如果从SVN代码库Check Out，不就把最新的未稳定的代码上线吗？”

读者，听完我的描述，你看到同事LL理解上的问题吗？软件版本号和配置管理有关系吗？怎么执行呢？

（未完待续）