查看“代码版本规约”的源代码

== 代码版本命名规约 ==

=== 命名格式 ===

<code>x.y.z.yyyymmdd</code>

{| class="wikitable"
|-
| x || 主版本号，起始于0的自然序号
|-
| y || 子版本号，起始于0的自然序号
|-
| z || 修正版本号，起始于0的自然序号
|-
| yyyymmdd || 产出日期（年月日）
|}

=== 管理策略 ===

* 初版版本号为0.0.1，进入内部测试流程，对外正式发布的初始版本号为1.0.0
* 当项目在进行了局部修改或bug修正时，主版本号和子版本号都不变，修正版本号加1
* 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加1，修正版本号复位为0
* 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加1，子版本号和修正版本号复位为0

=== 实例说明 ===

{| class="wikitable"
|-
| 0.0.1-SNAPSHOT || svn trunk目录中存放项目最新代码，版本<span style="color:red">固定</span>为<code>0.0.1-SNAPSHOT</code>
|-
| 0.1.6.20170116 || 2017年01月16日打包，系统仍处于内部测试阶段，
在此期间进行了1次较大功能的修改，且此后进行了6次局部修改或bug修正
|-
| 1.0.0.20170301 || 2017年03月01日打包，系统初次上线
|}

== SVN代码版本管理 ==

在项目的实现与测试阶段，SVN中共分了4个目录，方便进行代码的管理，具体如下：

{| class="wikitable"
|-
| trunk || 项目最新代码
|-
| branch || 对应tag中某版本的分支进行bug修复，修复完毕打包时修正版本号加1
|-
| tag || 打包版本的源码
|-
| commit || 打包版本的可执行程序及相关文件
|}

=== SVN代码存放示例图1 ===

<uml format="png">
|trunk|
|branch|
|tag|
|commit|

partition "内测初版 0.0.1-20170101" {
|trunk|
:project-0.0.1-SNAPSHOT;
|tag|
:project-0.0.1-20170101;
|commit|
:project-0.0.1-20170101
可执行程序及相关文件;
detach
}

partition "内测版 0.1.6.20170116" {
|trunk|
:project-0.0.1-SNAPSHOT;
|tag|
:project-0.1.6.20170116;
|commit|
:project-0.1.6.20170116
可执行程序及相关文件;
detach
}

partition "正式版 1.0.0.20170301" {
|trunk|
:project-0.0.1-SNAPSHOT;
|tag|
:project-1.0.0.20170301;
|commit|
:project-1.0.0.20170301
可执行程序及相关文件;
detach
}

partition "正式版 1.1.8.20170425" {
|trunk|
:project-0.0.1-SNAPSHOT;
|tag|
:project-1.1.8.20170425;
|commit|
:project-1.1.8.20170425
可执行程序及相关文件;
detach
}

partition "修复 1.0.0.20170301" {
|tag|
:project-1.0.0.20170301;
note
若今日(20140425)需要修复某地部署的
1.0.0.20170301版的程序bug，
可做此版程序的分支后进行修复，
修复完毕后重新进行打包
end note
|branch|
:project-1.0.0.20170301;
|tag|
:project-1.0.1.20170425;
note
打包时修正版本号加1
end note
|commit|
:project-1.0.1.20170425
可执行程序及相关文件;
detach
}
</uml>