乐者为王

Do one thing, and do it well.

软件版本号的思考

产品的名称用来表明产品目的,通常在产品的整个生命周期中都使用它。软件产品的版本号则用来表明产品在特定时间段内所拥有的功能集。它们关注的是以何种方式对提供给用户的软件版本进行识别。

版本号用于捕获相关产品修订和变种(通常与可移植性、国际化或者性能特征相关)的信息。目标是采用尽量少的标识符去收集所有信息。遗憾的是,在工业生产中还没有一种标准的版本编号机制,或者说,不存在单一的、通用的算法。更多情况是,需要你针对发布的内容和目标群体做些细微不同的调整。

但不管你的目标群体是什么,完全发布最好通过以下方式进行标识。这是经过不断地反复实践,被各种封闭、开源软件所广泛使用的惯例。

  • 软件的名称。
  • 用x.y.z.build四位元组去捕捉修订信息。
  • 根据需要生成的任意变种信息。

版本编号中的元组定义:

元组 定义
x 主版本号。表示产品的当前主要版本。用来表示提供给客户的产品功能的主要增强。在一个极端的例子中,主版本号的增加用来说明产品现在已经拥有一个全新的功能类。
y 次版本号。表示给产品新增了一些特征,或者是在原来文档中描述的特征上做了重要的修改。用来确定次版本号什么时候需要修改的一个衡量标准就是产品功能说明书。
z 修订版本号。用来表示给产品所做的缺陷维护行为的等级。产品缺陷是在产品的功能说明书中没有定义,并且已经或者可能对产品的使用者造成不利影响的任何行为。缺陷维护可以看作是支持该版本功能说明的一切活动。
build 构建版本号。一般是编译器在编译过程中自动生成。

除z和build的意义比较明确外,对x和y的解释都太笼统。我们需要更加详细的说明以指导我们的开发工作。

修订过的版本编号中的元组定义:

元组 定义
x 主版本号。用于有扩展性的、客户可见的架构上或特性上的改变。以一个管理大型数据库的系统为例,你可能在以下情况时需要定义一个主要的版本发布:
* 改变数据库的结构,导致单纯的升级系统对客户产生比较严重的影响。
* 改变已经发布的API,导致它与前一版本不兼容。
* 删除功能(好的架构师应该删除一些不需要的功能)。
* 持续增加新的功能,例如对新的操作系统的支持。
x的增加也可以是出于纯粹的商业理由。例如,客户的技术支持合同标明,在下个主要版本发布以后,软件可以得到18个月的技术支持。通过增加x,你将强迫客户去升级。
y 次版本号。通常与期望的功能或其它改进措施相关。当市场部门认为这个版本的一系列特性已经通过证实,次要版本号就会增加。决定增加x或y可能会比较随意。市场架构师应该定义触发任何一个增加的事件(定义与x相关的触发事件比定义y要更容易)。
z 修订版本号。主要版本号和次要版本号都相同的维护版本应该彼此兼容。
build 构建版本号。一般是编译器在编译过程中自动生成。

注意:这里的版本编号规则仅适用于发布周期较长的软件产品。如果发布周期很短,像Chrome和Firefox那样,可能就不太适用。

参考资料

  • 语义化版本
  • 《软件发布方法》
  • 《超越软件架构:创建和维护优秀解决方案》

Comments