研发规范-版本管理规范.docxVIP

1/6

LOGO

XX公司

密级

密级内部资料

版本管理规范

(Version1.0)

XX科技有限公司

2022年6月

2/6

LOGOXX公司

LOGO

文档名称文档编号起草时间

版本管理规范

2022-6姓名

2022-6

姓名

部门

文档信息

密级

发布版本

当前版本

内部资料

1.0

电话电

电话

起草人

审阅人

签发人

文档修改记录

序号修改时间修改人主要修改存档版本

1

2

3

4

5

6

7

8

9

10

3/6

LOGO

XX公司

版本管理规范

1目的 4

2合用范围 4

3版本管理规范 4

3.1版本管理工具 4

3.2版本库目录结构 4

3.3版本命名规范 5

3.3.1产品名称 5

3.3.2版本号 5

3.3.3版本标识 5

3.4版本提交规范 5

4/6

LOGO

XX公司

1目的

标识、控制和追踪软件开辟和实施过程中产生的各种软件产品版本。

2合用范围

合用于研发中心相关项目和产品所有软件文档和源代码版本的管理。

3版本管理规范

3.1版本管理工具

采用Subversion(SVN)进行版本管理。

3.2版本库目录结构

版本库目录结构如下所示：

第一层目录为wasu_XXXX(XXXX为项目或者产品名称缩写)，每一个项目或者产品的下层目录结构(第二层目录)如下：

trunk主开辟目录

branches分支开辟目录

release_tags发布版本存档目录(不允许修改)

这三个目录每一个目录下层目录结构(第三层目录)统一如下：

doc存放开辟过程中的文档

src存放代码

普通的，我们的所有的开辟都是基于trunk进行开辟，当一个版本/release开辟告一段落(开发、测试、文档、制作安装程序、打包等)结束后，代码处于冻结状态(人为规定)。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开辟任务开始，继续在trunk进行开辟。

此时，如果发现了上一个已发行版本(ReleasedVersion)有一些bug，或者一些很急迫的功能要求，而正在开辟的版本(DevelopingVersion)无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支(branch)进行开辟。

例如，刚刚发布1.0，正在开辟2.0，此时要在1.0的基础上进行bug修正。按照时间的顺序：

1.1.0开辟完毕，代码冻结

2.基于已经冻结的trunk，为release1.0打tag

此时的目录结构为

svn://proj/

+trunk/?(freeze)

+branches/

+release_tags/

++tag_release_1.0(copyfromtrunk)

3.2.0开始开辟，trunk此时为2.0的开辟版

4.发现1.0有bug，需要修改，基于1.0的tag做branch

此时的目录结构为

svn://proj/

+trunk/?(dev2.0)

+branches/

++branch_dev_1.0_bugfix(copyfromtag/release_1.0)

+release_tags/

5/6

LOGO

XX公司

++tag_release_1.0(copyfromoldtrunk)

5.在1.0bugfixbranch进行1.0bugfix开辟，在trunk进行2.0开辟

6.在1.0bugfix完成之后，基于branch_dev_1.0_bugfix的branch做release等

7.根据需要选择性的把branch_dev_1.0_bugfix这个分支merge回trunk(什么时候进行这步操作，要根据具体情况)

3.3版本命名规范

3.3.1产品名称

新产品立项时，为产品赋予版本库中的产品名称；当已有产品升级时，则沿用前一版本产品

的名称。

版本库中的产品名称暂定为wasu_XXXX(XXXX为产品中文名称首字母组成或者产品英文名称)，作为版本库该产品的首层目录名。

3.3.2版本号

版本号用来标识发布产品，版本号格式为：

主版本号.副版本号

主版本号：立项时设置

1新产品立项，主版