Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
Crayon鑫
Paddle
提交
812093c0
P
Paddle
项目概览
Crayon鑫
/
Paddle
与 Fork 源项目一致
Fork自
PaddlePaddle / Paddle
通知
1
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
1
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
P
Paddle
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
1
Issue
1
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
提交
812093c0
编写于
4月 20, 2017
作者:
Y
Yu Yang
提交者:
GitHub
4月 20, 2017
浏览文件
操作
浏览文件
下载
差异文件
Merge pull request #1812 from reyoung/feature/doc_about_releasing_process
Releasing Paddle Standard.
上级
8bcb9f2c
2f633a6e
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
58 addition
and
0 deletion
+58
-0
doc/design/releasing_process.md
doc/design/releasing_process.md
+58
-0
未找到文件。
doc/design/releasing_process.md
0 → 100644
浏览文件 @
812093c0
# Paddle发行规范
Paddle使用git-flow branching model做分支管理,使用
[
Semantic Versioning
](
http://semver.org/
)
标准表示Paddle版本号。
Paddle每次发新的版本,遵循以下流程:
1.
从
`develop`
分支派生出新的分支,分支名为
`release/版本号`
。例如,
`release/0.10.0`
2.
将新分支的版本打上tag,tag为
`版本号rc.Patch号`
。第一个tag为
`0.10.0rc1`
,第二个为
`0.10.0rc2`
,依次类推。
3.
对这个版本的提交,做如下几个操作:
*
编译这个版本的Docker发行镜像,发布到dockerhub。如果失败,修复Docker编译镜像问题,Patch号加一,返回第二步
*
编译这个版本的Ubuntu Deb包。如果失败,修复Ubuntu Deb包编译问题,Patch号加一,返回第二步。
*
使用Regression Test List作为检查列表,测试Docker镜像/ubuntu安装包的功能正确性
*
如果失败,记录下所有失败的例子,在这个
`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的书写
需要注意的是:
*
`release/版本号`
分支一旦建立,一般不允许再从
`develop`
分支合入
`release/版本号`
。这样保证
`release/版本号`
分支功能的封闭,方便测试人员测试Paddle的行为。
*
在
`release/版本号`
分支存在的时候,如果有bugfix的行为,需要将bugfix的分支同时merge到
`master`
,
`develop`
和
`release/版本号`
这三个分支。
# 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`
分支的版本都经过单元测试,但并没有经过回归测试。
*
`release/版本号`
分支为每一次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`
与可能有的
`release/版本号`
分支,同时提起
`Pull Request`
。
# 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.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录