Follow comments

doc/design/releasing_process/01.how_to_release_paddle.md

@@ -4,19 +4,19 @@ Paddle使用[git-flow](./02.paddle_branching_model.md) branching model做分支
 
 Paddle每次发新的版本，遵循以下流程:
 
-1. 从`develop`分支派生出新的分支，分支名为`版本号rc`。例如，`0.10.0rc`
-2. 将新分支的版本打上tag，tag为`版本号rc.Patch号`。第一个tag为`0.10.0rc0`，第二个为`0.10.0rc1`，依次类推。
+1. 从`develop`分支派生出新的分支，分支名为`release/版本号`。例如，`release/0.10.0`
+2. 将新分支的版本打上tag，tag为`版本号rc.Patch号`。第一个tag为`0.10.0rc1`，第二个为`0.10.0rc2`，依次类推。
 3. 对这个版本的提交，做如下几个操作:
-	* 编译这个版本的Docker发行镜像，发布到dockerhub。如果失败，Patch号加一，返回第二步
-	* 编译这个版本的Ubuntu Deb包。如果失败，Patch号加一，返回第二步。
+	* 编译这个版本的Docker发行镜像，发布到dockerhub。如果失败，修复Docker编译镜像问题，Patch号加一，返回第二步
+	* 编译这个版本的Ubuntu Deb包。如果失败，修复Ubuntu Deb包编译问题，Patch号加一，返回第二步。
 	* 使用[Regression Test List](./03.regression_test_list.md)作为检查列表，测试Docker镜像/ubuntu安装包的功能正确性
-		* 如果失败，记录下所有失败的例子，在这个`rc`分支中，修复所有bug后，Patch号加一，返回第二步
-4. 第三步完成后，将`rc`分支合入master分支，并删除`rc`分支。将master分支的合入commit打上tag，tag为`版本号`。同时再将`master`分支合入`develop`分支。最后删除`rc`分支。
+		* 如果失败，记录下所有失败的例子，在这个`release/版本号`分支中，修复所有bug后，Patch号加一，返回第二步
+4. 第三步完成后，将`release/版本号`分支合入master分支，并删除`release/版本号`分支。将master分支的合入commit打上tag，tag为`版本号`。同时再将`master`分支合入`develop`分支。最后删除`release/版本号`分支。
 5. 编译master分支的Docker发行镜像，发布到dockerhub。编译ubuntu的deb包，发布到github release页面
 6. 协同完成Release Note的书写
 
 
 需要注意的是:
 
-* `rc`分支一旦建立，一般不允许再从`develop`分支合入`rc`。这样保证`rc`分支功能的封闭，方便测试人员测试Paddle的行为。
-* 在`rc`分支存在的时候，如果有bugfix的行为，需要将bugfix的分支同时merge到`master`, `develop`和`rc`这三个分支。
+* `release/版本号`分支一旦建立，一般不允许再从`develop`分支合入`release/版本号`。这样保证`release/版本号`分支功能的封闭，方便测试人员测试Paddle的行为。
+* 在`release/版本号`分支存在的时候，如果有bugfix的行为，需要将bugfix的分支同时merge到`master`, `develop`和`release/版本号`这三个分支。

doc/design/releasing_process/02.paddle_branching_model.md

@@ -5,7 +5,7 @@ Paddle开发过程使用[git-flow](http://nvie.com/posts/a-successful-git-branch
 * Paddle的主版本库遵循[git-flow](http://nvie.com/posts/a-successful-git-branching-model/)分支规范。其中:
 	* `master`分支为稳定(stable branch)版本分支。每一个`master`分支的版本都是经过单元测试和回归测试的版本。
 	* `develop`分支为开发(develop branch)版本分支。每一个`develop`分支的版本都经过单元测试，但并没有经过回归测试。
-	* `rc`分支为每一次Release时建立的临时分支。在这个阶段的代码正在经历回归测试。
+	* `release/版本号`分支为每一次Release时建立的临时分支。在这个阶段的代码正在经历回归测试。
 
 * 其他用户的fork版本库并不需要严格遵守[git-flow](http://nvie.com/posts/a-successful-git-branching-model/)分支规范，但所有fork的版本库的所有分支都相当于特性分支。
 	* 建议，开发者fork的版本库使用`develop`分支同步主版本库的`develop`分支
@@ -13,4 +13,4 @@ Paddle开发过程使用[git-flow](http://nvie.com/posts/a-successful-git-branch
 	* 当功能分支开发完毕后，向Paddle的主版本库提交`Pull Reuqest`，进而进行代码评审。
 		* 在评审过程中，开发者修改自己的代码，可以继续在自己的功能分支提交代码。 
 
-* BugFix分支也是在开发者自己的fork版本库维护，与功能分支不同的是，BugFix分支需要分别给主版本库的`master`、`develop`与可能有的`rc`分支，同时提起`Pull Request`。
+* BugFix分支也是在开发者自己的fork版本库维护，与功能分支不同的是，BugFix分支需要分别给主版本库的`master`、`develop`与可能有的`release/版本号`分支，同时提起`Pull Request`。