Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
PaddlePaddle
Paddle
提交
81c6211c
P
Paddle
项目概览
PaddlePaddle
/
Paddle
大约 1 年 前同步成功
通知
2298
Star
20931
Fork
5422
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
1423
列表
看板
标记
里程碑
合并请求
543
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
P
Paddle
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
1,423
Issue
1,423
列表
看板
标记
里程碑
合并请求
543
合并请求
543
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
81c6211c
编写于
4月 19, 2017
作者:
Y
Yu Yang
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Releasing Paddle Standard.
上级
8239fbe6
变更
3
隐藏空白更改
内联
并排
Showing
3 changed file
with
56 addition
and
0 deletion
+56
-0
doc/design/releasing_process/01.how_to_release_paddle.md
doc/design/releasing_process/01.how_to_release_paddle.md
+22
-0
doc/design/releasing_process/02.paddle_branching_model.md
doc/design/releasing_process/02.paddle_branching_model.md
+16
-0
doc/design/releasing_process/03.regression_test_list.md
doc/design/releasing_process/03.regression_test_list.md
+18
-0
未找到文件。
doc/design/releasing_process/01.how_to_release_paddle.md
0 → 100644
浏览文件 @
81c6211c
# Paddle发行规范
Paddle使用
[
git-flow
](
./02.paddle_branching_model.md
)
branching model做分支管理,使用
[
Semantic Versioning
](
http://semver.org/
)
标准表示Paddle版本号。
Paddle每次发新的版本,遵循以下流程:
1.
从
`develop`
分支派生出新的分支,分支名为
`版本号rc`
。例如,
`0.10.0rc`
2.
将新分支的版本打上tag,tag为
`版本号rc.Patch号`
。第一个tag为
`0.10.0rc0`
,第二个为
`0.10.0rc1`
,依次类推。
3.
对这个版本的提交,做如下几个操作:
*
编译这个版本的Docker发行镜像,发布到dockerhub。如果失败,Patch号加一,返回第二步
*
编译这个版本的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`
分支。
5.
编译master分支的Docker发行镜像,发布到dockerhub。编译ubuntu的deb包,发布到github release页面
6.
协同完成Release Note的书写
需要注意的是:
*
`rc`
分支一旦建立,一般不允许再从
`develop`
分支合入
`rc`
。这样保证
`rc`
分支功能的封闭,方便测试人员测试Paddle的行为。
*
在
`rc`
分支存在的时候,如果有bugfix的行为,需要将bugfix的分支同时merge到
`master`
,
`develop`
和
`rc`
这三个分支。
doc/design/releasing_process/02.paddle_branching_model.md
0 → 100644
浏览文件 @
81c6211c
# Paddle 分支规范
Paddle开发过程使用
[
git-flow
](
http://nvie.com/posts/a-successful-git-branching-model/
)
分支规范,并适应github的特性做了一些区别。
*
Paddle的主版本库遵循
[
git-flow
](
http://nvie.com/posts/a-successful-git-branching-model/
)
分支规范。其中:
*
`master`
分支为稳定(stable branch)版本分支。每一个
`master`
分支的版本都是经过单元测试和回归测试的版本。
*
`develop`
分支为开发(develop branch)版本分支。每一个
`develop`
分支的版本都经过单元测试,但并没有经过回归测试。
*
`rc`
分支为每一次Release时建立的临时分支。在这个阶段的代码正在经历回归测试。
*
其他用户的fork版本库并不需要严格遵守
[
git-flow
](
http://nvie.com/posts/a-successful-git-branching-model/
)
分支规范,但所有fork的版本库的所有分支都相当于特性分支。
*
建议,开发者fork的版本库使用
`develop`
分支同步主版本库的
`develop`
分支
*
建议,开发者fork的版本库中,再基于
`develop`
版本fork出自己的功能分支。
*
当功能分支开发完毕后,向Paddle的主版本库提交
`Pull Reuqest`
,进而进行代码评审。
*
在评审过程中,开发者修改自己的代码,可以继续在自己的功能分支提交代码。
*
BugFix分支也是在开发者自己的fork版本库维护,与功能分支不同的是,BugFix分支需要分别给主版本库的
`master`
、
`develop`
与可能有的
`rc`
分支,同时提起
`Pull Request`
。
doc/design/releasing_process/03.regression_test_list.md
0 → 100644
浏览文件 @
81c6211c
# Paddle回归测试列表
本列表说明Paddle发版之前需要测试的功能点。
## Paddle Book中所有章节
Paddle每次发版本首先要保证Paddle Book中所有章节功能的正确性。功能的正确性包括验证Paddle目前的
`paddle_trainer`
训练和纯使用
`Python`
训练模型正确性。
| | 新手入门章节 | 识别数字 | 图像分类 | 词向量 | 情感分析 | 语意角色标注 | 机器翻译 | 个性化推荐 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| API.V2 + Docker + GPU |
| API.V2 + Docker + CPU |
|
`paddle_trainer`
+ Docker + GPU |
|
`paddle_trainer`
+ Docker + CPU |
| API.V2 + Ubuntu + GPU |
| API.V2 + Ubuntu + CPU |
|
`paddle_trainer`
+ Ubuntu + GPU |
|
`paddle_trainer`
+ Ubuntu + CPU |
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录