有任何疑问,欢迎提交 issue, 或者直接修改提交 PR!
随后 imove 负责人会确认 issue 意图,更新合适的标签,关联 milestone,指派开发者。
标签可分为两类,type 和 scope
feature
, bug
, documentation
, performance
, support
...core: xx
,plugin: xx
,deps: xx
support
: issue 提出的问题需要开发者协作排查,咨询,调试等等日常技术支持。bug
: 一旦发现可能是 bug 的问题,请打上 bug
,然后等待确认,一旦确认是 bug,此 issue 会被再打上 confirmed
。
critical
,代表是最高优先级,需要马上立刻处理!0.9.x
要修复的,而当前最新版本是 1.1.x
,
那么此 issue 还会被打上 0.9
,0.10
,1.0
,1.1
,代表需要修复到这些版本。core: xx
: 代表 issue 跟 core 内核相关,如 core: antx
代表跟 antx
配置相关。plugin: xx
: 代表 issue 跟插件相关,如 deps: session
代表跟 session
插件相关。deps: xx
: 代表 issue 跟 dependencies
模块相关,如 deps: egg-cors
代表跟 egg-cors
模块相关。chore: documentation
: 代表发现了文档相关问题,需要修复文档说明。cbd
: 代表跟服务器部署相关所有功能点必须提交配套文档,文档须满足以下要求
如果你有仓库的开发者权限,而且希望贡献代码,那么你可以创建分支修改代码提交 PR,ykfe 开发团队会 review 代码合并到主干。
# 先创建开发分支开发,分支名应该有含义,避免使用 update、tmp 之类的
$ git checkout -b branch-name
# 开发完成后跑下测试是否通过,必要时需要新增或修改测试用例
$ npm test
# 测试通过后,提交代码,message 见下面的规范
$ git add . # git add -u 删除文件
$ git commit -m "fix(role): role.use must xxx"
$ git push origin branch-name
由于谁也无法保证过了多久之后还记得多少,为了后期回溯历史的方便,请在提交 MR 时确保提供了以下信息。
你的代码风格必须通过 eslint,你可以运行 $ npm run lint
本地测试。
根据 angular 规范提交 commit, 这样 history 看起来更加清晰,还可以自动生成 changelog。
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
(1)type
提交 commit 的类型,包括以下几种
(2)scope
修改文件的范围(包括但不限于 doc, middleware, core, config, plugin)
(3)subject
用一句话清楚的描述这次提交做了什么
(4)body
补充 subject,适当增加原因、目的等相关因素,也可不写。
(5)footer
Closes #1, Closes #2, #3
doc
和 egg-core
的 PR,如 eggjs/egg-core#123
示例
fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Document change on eggjs/egg#123
Closes #392
BREAKING CHANGE:
Breaks foo.bar api, foo.baz should be used instead
详情请查看具体文档。
英语正文按照一般英语语法规律书写即可,但标题比较特殊,应该按照以下规范进行书写:
有关详情,可以参考英语标题大小写。
imove 基于 semver 语义化版本号进行发布。
master
分支为当前稳定发布的版本,next
分支为下一个开发中的大版本。
master
和 next
分支,其他更新推动上层框架升级到稳定大版本的最新版本。deprecate
提示,并保证在当前的稳定版本上一直兼容到新版本的发布。master
分支不设置 publish tag,上层框架基于 semver 依赖稳定版本。next
分支设置 tag 为 next
,上层框架可以通过 egg@next
引用开发中的版本进行测试。每个大版本都有一个发布经理管理(PM),他/她要做的事情
master
分支新建 next
分支,并设置 tag 为 next
。History
的编写,修正文档中与版本相关的内容,commits 可以自动生成。
$ npm run commits
1.x
),并设置 tag 为 release-{v}.x
( v 为当前版本,例如 release-1.x
)。next
分支推送到 master
,成为新的稳定版本分支,并去除 next
tag,修改 README 中与分支相关的内容。npm publish
之前,请先阅读 我是如何发布一个 npm 包的。上述描述中所有的设置 tag 都是指在 package.json
中设置 npm 的 tag。
"publishConfig": {
"tag": "next"
}
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。