Releasing Paddle Standard. #1812
Conversation
reyoung
force-pushed
the
feature/doc_about_releasing_process
branch
from
cb8b509
to
81c6211
Compare
| Paddle每次发新的版本，遵循以下流程: | ||
|
|
||
| 1. 从`develop`分支派生出新的分支，分支名为`版本号rc`。例如，`0.10.0rc` | ||
| 2. 将新分支的版本打上tag，tag为`版本号rc.Patch号`。第一个tag为`0.10.0rc0`，第二个为`0.10.0rc1`，依次类推。 |
| * 编译这个版本的Docker发行镜像，发布到dockerhub。如果失败，Patch号加一，返回第二步 | ||
| * 编译这个版本的Ubuntu Deb包。如果失败，Patch号加一，返回第二步。 | ||
| * 使用[Regression Test List](./03.regression_test_list.md)作为检查列表，测试Docker镜像/ubuntu安装包的功能正确性 | ||
| * 如果失败，记录下所有失败的例子，在这个`rc`分支中，修复所有bug后，Patch号加一，返回第二步 |
There was a problem hiding this comment.
应该是先验证Docker镜像生成正确，deb包生成正确，Regression Test List验证正确再打tag？
There was a problem hiding this comment.
这里，如果Docker镜像生成或者deb包生成失败的话，还是应该先去Fix这些问题，bump up版本好。。
因为QA同学真正拿到手的测试文件是Docker镜像或者Deb包。。如果某个版本build二进制包就失败了，QA同学也没法做后续的Regression Test List.
There was a problem hiding this comment.
明白了。那是不是build Docker镜像和deb包的ci功能加上了，也可以省略手动测试编Docker的步骤？
|
|
||
| Paddle每次发新的版本，遵循以下流程: | ||
|
|
||
| 1. 从`develop`分支派生出新的分支，分支名为`版本号rc`。例如，`0.10.0rc` |
There was a problem hiding this comment.
或者直接创建release branch，而不是rc branch？在merge到master之前的tag为rc?
reyoung
force-pushed
the
feature/doc_about_releasing_process
branch
from
90fee11
to
6f6dca3
Compare
| 需要注意的是: | ||
|
|
||
| * `release/版本号`分支一旦建立，一般不允许再从`develop`分支合入`release/版本号`。这样保证`release/版本号`分支功能的封闭，方便测试人员测试Paddle的行为。 | ||
| * 在`release/版本号`分支存在的时候，如果有bugfix的行为，需要将bugfix的分支同时merge到`master`, `develop`和`release/版本号`这三个分支。 |
There was a problem hiding this comment.
release验证完毕后会合入到master，master又会合入到develop，所以这个release上的bugfix看起来可以不用单独往master和develop merge？
There was a problem hiding this comment.
release的时间周期可能很长，如果发现了一个严重的bug，只merge回release分支可能会让develop分支长期没有fix这个bug，导致RD比较不开心。
当然，如果是不严重的问题，现在release 分支fix了，再合并回去，也是可以的。
|
|
||
| 1. 从`develop`分支派生出新的分支，分支名为`release/版本号`。例如，`release/0.10.0` | ||
| 2. 将新分支的版本打上tag，tag为`版本号rc.Patch号`。第一个tag为`0.10.0rc1`，第二个为`0.10.0rc2`，依次类推。 | ||
| 3. 对这个版本的提交，做如下几个操作: |
There was a problem hiding this comment.
这里打tag的流程是不是有问题。我理解打上tag之后，就应该完全通过测试了，因此，不需要给预发布分支打tag。
这里是不是应该这样做：
1 先从develop拉上一个预发布分支，release/版本号
2 然后对该release/版本号分支进行发布docker，deb包，回归测试等
3 如果全部通过，同时merge到master，develop，再打上tag
4 如果失败，修改相应代码，返回步骤2
There was a problem hiding this comment.
那就没有rc的过程了呀。
这里其实主要做到的是，QA和开发人员的解耦。。QA只需要看Paddle版本库里面的二进制，来测试就好。打一些rc的tag是为了给QA标记出来正在release过程中的二进制。
从QA的视角看，他会发现Paddle的二进制库中增加了新的版本的二进制，进而进行全量回归测试。再告诉RD，哪个版本有问题。。所以这些rc版本都是QA和RD沟通的中间版本。
|
|
||
| 1. 从`develop`分支派生出新的分支，分支名为`release/版本号`。例如，`release/0.10.0` | ||
| 2. 将新分支的版本打上tag，tag为`版本号rc.Patch号`。第一个tag为`0.10.0rc1`，第二个为`0.10.0rc2`，依次类推。 | ||
| 3. 对这个版本的提交，做如下几个操作: |
| @@ -0,0 +1,22 @@ | |||
| # Paddle发行规范 | |||
There was a problem hiding this comment.
这三个文件每一个都很短，是不是合为一个就好了？
| @@ -0,0 +1,22 @@ | |||
| # Paddle发行规范 | |||
|
|
|||
| Paddle使用[git-flow](./02.paddle_branching_model.md) branching model做分支管理，使用[Semantic Versioning](http://semver.org/)标准表示Paddle版本号。 | |||
There was a problem hiding this comment.
我看semantic version里说：
MAJOR version when you make incompatible API changes,
那这个版本是不是得叫1.0.xxx 了，而不是 0.10.xxx 了？
There was a problem hiding this comment.
目前这个版本还是compatible的API changes
|
|
||
| Paddle每次发新的版本，遵循以下流程: | ||
|
|
||
| 1. 从`develop`分支派生出新的分支，分支名为`release/版本号`。例如，`release/0.10.0` |
There was a problem hiding this comment.
我建议branch name里不要用/，因为这样一来remote branch的名字里有的/是URL自带的，有的是 branch name里的。改成-感觉更好一些。
一点参考：
- 我看Go 的 branch name叫
release-branch.go1.2这样。 - TensorFlow的rc叫
v1.1.0-rc1，而release叫r1.1。
There was a problem hiding this comment.
其实，在git-flow的标准里还是用/的，而且这次的release branch已经创建出来了。。我先在文档里面改过来，下次release的时候我们再把BranchName改过来。。
Fix #1670
其实这里的主题思想是，使用RC分支和tag，让开发人员和测试人员解耦合。测试人员只需要关注测试新增的二进制，开发人员只需要关注开发Paddle，Fix 测试人员反馈的Bug即可