Merge branch '4.2/2514'

Conflicts:
	README.md

README.md

@@ -6,4 +6,6 @@
 
 ## [linx6.0.42.41自动编译环境搭建说明](autobuild.md) ##
 
-## [操作系统版本以及对应光盘版本说明](OS-version-node.md) ##
+## [操作系统版本以及对应光盘版本说明](OS-version-node.md) ##
+
+## [linx6.0.42.41新版发布实现说明](release_stable.md) ##

release_stable.md

@@ -0,0 +1,122 @@
+# Linx6.0.42.41发布方法说明文档 #
+
+## 1 引言 ##
+
+### 1.1 概述 ###
+
+本文档为发布Linx6.0.42.41系统正式版的发布方法说明文档。主要介绍发布正式版的发布方法及发布方法的实现说明。以便实施人员执行发布正式版，及了解发布的实现流程。
+
+### 1.2 适用范围 ###
+
+本文档适用于Linx6.0.42.41系统的发布，基于Linx6.0.42.41自动编译系统实现的发布方法。
+
+此发布新版本的方法需在搭建好的自动编译环境中才可使用。
+
+### 1.3 参考资料 ###
+
+【1】《搭建4.2自动编译环境说明》，V0.1，徐顺选
+
+ ## 2 发布Linx6.0.42.41 ##
+
+ ### 2.1 版本正式发布介绍 ###
+
+ Linx6.0.42.41自动编译系统，通过每天零点检测4.2的各个git库主线是否有新提交，来决定是否进行编译出盘。每次git库的merge都为修复bug、升级系统包版本或者添加系统包。故每过一段时间需要发布一版正式版本的系统。故编写相应的便于发布正式版的程序来实现此需求。
+
+ 此发布程序的基本实现过程简介：
+
+ 1.检测要发布日期版本的系统盘是否存在;
+
+ 2.制作新版发布版与上一版发布的升级包集合留存;
+
+ 3.添加发布目录到服务器的stable-iso中;
+
+ 4.提交新发布日期的tag;
+
+ 5.获取新版发布与上一版之间的log提交及log对应的bug摘要;
+
+ 6.制作markdown文件并转为pdf文档和html文件;
+
+ 7.发送邮件通知。
+
+ ### 2.2 版本正式发布准备 ###
+
+ 发布版本为dailybuild发布的其中一版。此次说明为以172.16.0.250服务器为示例说明服务器、以服务器上的虚拟机172.16.250.122为运行环境。用到的服务器中的内容为：所有包的集合/home/builder/x86_64（以日期为分组，制作光盘的取包池），daily-build的发布版目录（获取其中的发布盘及log等），以服务器发送邮件通知。
+
+ #### 2.2.1 代码库准备 ####
+
+ 此新版发布的程序需要在4.2自动编译环境中执行。release_stable相关的发布程序均已添加到autobuild-tools的git库中。此外还需debian8.0的最小环境，用于使用pandoc完成markdown转换。
+
+ autobuild-tools工具集合库下载：
+
+```
+git clone http://gitlab.rd.in.linx/linx6.0.42/autobuild-tools.git
+```
+
+ debian8.0最小环境下载：
+
+```
+wget http://172.16.0.85/chroot-env/base-jessie_amd64.cow.xz
+```
+
+ 解压后的debian8.0最小环境中，还需添加pandoc需要的转换工具,下载：
+
+```
+git clone git@gitlab.rd.in.linx:linx6.0.42/progit.git
+```
+
+关于debian8.0最小环境中的pandoc使用配置，请参阅《搭建4.2自动编译环境说明》。
+
+ #### 2.2.2 使用说明 ####
+
+1.release_stable.sh发布新版。
+
+根据日常检测编译中的日期，创建新发布版示例：
+
+```
+./release_stable.sh 2015-01-23-005001 2015-05-29-141155
+```
+
+(说明：后面的日期参数为日常检测目录中的日期/home/builser/x86_64:第一个日期为上次发布版的日期，第二个日期为本次发布的日期)
+
+release_stable.sh中调用getupdate.sh,用于创建新发布版与上一版本之间的pkg升级包集合。生成的update包集合，在home/builder/stable-iso/isoUpdates中。
+
+2.getupdate.sh:获得/home/builder/x86_64目录下的两个时间检测点之间的升级包集合。若两个时间点之间同一个包有两个版本（做过两次修改或升级），则只将高版本的包取出。
+
+使用示例：(后面的日期参数为日常检测目录中的日期/home/builser/x86_64)
+```
+./getupdate.sh 2015-01-23-005001 2015-05-19-092752
+```
+
+正常运行结果：在/home/builder/x86_64/isoUpdates中生成两个时间点间升级或修改的所有包的tar包。
+
+## 3 新版发布实现说明 ##
+
+### 3.1 实现流程 ###
+
+运行发布脚本release_stable.sh后，即会检测发布对应的两个日期对应的daily-build：前一个日期对应的daily-build发布为前一次正式版发布的日期，后一个日期对应的daily-build发布为此次新版发布的日期。检测发布日期的daily-build是否存在，里面是否有*.iso文件等。
+
+检测存在之后，则会创建新版发布的目录。（添加软链接指向daily-build中要发布的日期）
+
+接下来，则是对新版发布的界面、信息记录、升级包集合等的处理：
+
+* 调用getupdate.sh处理/home/builder/x86_64目录中的发布日期之间的升级包，获取各升级包的最高版本集成升级包集合，存放到发布界面的同级目录isoUpdates中；
+
+* 提交新发布时的各个git库的tag;
+
+* 获取自上次发布至本次发布之间的所有的git log（通过集合两次日期之间的所有日期的每一次git提交信息获得：在daily-build中均存在此记录）；
+
+* 通过处理获得的git log集合，获得符合markdown格式的发布说明文档；
+
+* 将markdown文档传送到debian8.0的最小环境中，使用pandoc进行处理：生成html文件及pdf文档，发回到发布目录下；
+
+* 发布页面及发布文档等已完成，调用send_mail在服务器上发送邮件说明通知。
+
+### 3.2 注意事项 ###
+
+由于目前发布内容，文档等还需修改完善，故有时发布需要反复测试。测试注意：
+
+关于提交git库的tag，默认release_stable.sh脚本中是注掉的。由于多次测试发布内容及生成文档，不能每次都提交相同日期的tag。
+
+正式发布时，需要将release_stable.sh中的main中关于调用提交tag的两行前面的“#”去掉。
+
+## 4 结束 ##