关于项目版本号命名的规范与原则
软件版本阶段说明
Alpha版
此版本表示该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的Bug较多,需要继续修改
Beta版
版本相对于α版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的UI
RC版
该版本已经相当成熟了,基本上不存在导致错误的BUG,与即将发行的正式版相差无几
Release版:
该版本意味“最终版本”,在前面版本的一系列测试版之后,终归会有一个正式版本,是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下,Release不会以单词形式出现在软件封面上,取而代之的是符号(R)
在上面我们大致了解了软件从开发到交付会经历4个版本阶段,而当我们开始搭建一个新项目时,不可避免地要配置 package.json 文件,这个 version 怎么命名呢?
// package.json
{
"name": "项目名称",
"version": "0.1.0",
"description": "项目描述",
"author": "项目作者",
"license": "MIT",
}
版本命名规范
在说版本命名规范之前,先说说比较流行的版本命名格式
GNU 风格
Windows 风格
.Net Framework 风格
最常见的版本命名格式就是 GNU 风格,下面以 GNU 风格展开说明
主版本号.子版本号.修正(或阶段)版本号.日期版本号_希腊字母版本号
希腊字母版本号共有5种,分别为:base、alpha、beta、RC、release
版本命名修改规则
项目初版本时,版本号可以为 0.1.0
希腊字母版本号(beta)
此版本号用于标注当前版本的软件处于哪个开发阶段,当软件进入到另一个阶段时需要修改此版本号
日期版本号
用于记录修改项目的当前日期,每天对项目的修改都需要更改日期版本号(只有此版本号才可由开发人员决定是否修改)
修正(或阶段)版本号改动
当项目在进行了局部修改或bug修正时,主版本号和子版本号都不变,修正版本号加1
// package.json
{
"name": "项目名称",
"version": "0.1.0",
"version": "0.1.1",
}子版本号改动
当项目在原有基础上增加了某些功能模块时,比如增加了对权限控制、增加自定义视图等功能,主版本号不变,子版本号加1,修正版本号复位为0
// package.json
{
"name": "项目名称",
"version": "0.1.8",
"version": "0.2.0",
}主版本号改动
当项目在进行了重大修改或局部修正累积较多,而导致项目整体发生全局变化时,比如增加多个模块或者重构,主版本号加 1
// package.json
{
"name": "项目名称",
"version": "0.1.0", // 一期项目
"version": "1.1.0", // 二期项目
"version": "2.1.0", // 三期项目
}
文件命名规范
文件名称由四部分组成:第一部分为项目名称,第二部分为文件的描述,第三部分为当前软件的版本号,第四部分为文件阶段标识加文件后缀
例如:xx后台管理系统测试报告1.1.1.031222_beta_d.xls,此文件为xx后台管理系统的测试报告文档,版本号为:1.1.1.031222_beta
如果是同一版本同一阶段的文件修改过两次以上,则在阶段标识后面加以数字标识,每次修改数字加1,xx后台管理系统测试报告1.1.1.031222_beta_d1.xls
当有多人同时提交同一份文件时,可以在阶段标识的后面加入人名或缩写来区别,例如:xx后台管理系统测试报告 1.1.1.031222_beta_d_spp.xls。当此文件再次提交时也可以在人名或人名缩写的后面加入序号来区别,例如:xx后台管理系统测试报告1.1.1.031222_beta_d_spp2.xls
阶段标识
软件的每个版本中包括11个阶段,详细阶段描述如下:
阶段名称 | 阶段标识 |
---|---|
需求控制 | a |
设计阶段 | b |
编码阶段 | c |
单元测试 | d |
单元测试修改 | e |
集成测试 | f |
集成测试修改 | g |
系统测试 | h |
系统测试修改 | i |
验收测试 | j |
验收测试修改 | k |
作者:Jesse90s
来源:https://juejin.cn/post/7073902470585384990