UNPKG

4.88 kBMarkdownView Raw
1# 代码贡献规范
2
3有任何疑问，欢迎提交 [issue](https://github.com/antvis/data-set/issues)，
4或者直接修改提交 [PR](https://github.com/antvis/data-set/pulls)!
5
6## 提交 issue
7
8- 请确定 issue 的类型。
9- 请避免提交重复的 issue，在提交之前搜索现有的 issue。
10- 在标签(分类参考**标签分类**), 标题 或者内容中体现明确的意图。
11
12随后 AntV 负责人会确认 issue 意图，更新合适的标签，关联 milestone，指派开发者。
13
14## 提交代码
15
16### 提交 Pull Request
17
18如果你有仓库的开发者权限，而且希望贡献代码，那么你可以创建分支修改代码提交 PR，AntV 开发团队会 review 代码合并到主干。
19
20```bash
21# 先创建开发分支开发，分支名应该有含义，避免使用 update、tmp 之类的
22$ git checkout -b branch-name
23
24# 开发完成后跑下测试是否通过，必要时需要新增或修改测试用例
25$ npm test
26
27# 测试通过后，提交代码，message 见下面的规范
28
29$ git add . # git add -u 删除文件
30$ git commit -m "fix(role): role.use must xxx"
31$ git push origin branch-name
32```
33
34提交后就可以在 [data-set](https://github.com/antvis/data-set/pulls) 创建 Pull Request 了。
35
36由于谁也无法保证过了多久之后还记得多少，为了后期回溯历史的方便，请在提交 MR 时确保提供了以下信息。
37
381. 需求点（一般关联 issue 或者注释都算）
392. 升级原因（不同于 issue，可以简要描述下为什么要处理）
403. 框架测试点（可以关联到测试文件，不用详细描述，关键点即可）
414. 关注点（针对用户而言，可以没有，一般是不兼容更新等，需要额外提示）
42
43### 代码风格
44
45你的代码风格必须通过 eslint，你可以运行 `$ npm run lint` 本地测试。
46
47### Commit 提交规范
48
49根据 [angular 规范](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format)提交 commit，
50这样 history 看起来更加清晰，还可以自动生成 changelog。
51
52```xml
53<type>(<scope>): <subject>
54<BLANK LINE>
55<body>
56<BLANK LINE>
57<footer>
58```
59
60（1）type
61
62提交 commit 的类型，包括以下几种
63
64- feat: 新功能
65- fix: 修复问题
66- docs: 修改文档
67- style: 修改代码格式，不影响代码逻辑
68- refactor: 重构代码，理论上不影响现有功能
69- perf: 提升性能
70- test: 增加修改测试用例
71- chore: 修改工具相关（包括但不限于文档、代码生成等）
72- deps: 升级依赖
73
74（2）scope
75
76修改文件的范围
77
78（3）subject
79
80用一句话清楚的描述这次提交做了什么
81
82（4）body
83
84补充 subject，适当增加原因、目的等相关因素，也可不写。
85
86（5）footer
87
88- **当有非兼容修改(Breaking Change)时必须在这里描述清楚**
89- 关联相关 issue，如 `Closes #1, Closes #2, #3`
90
91示例
92
93```
94fix($compile): [BREAKING_CHANGE] couple of unit tests for IE9
95
96Older IEs serialize html uppercased, but IE9 does not...
97Would be better to expect case insensitive, unfortunately jasmine does
98not allow to user regexps for throw expectations.
99
100Document change on antvis/data-set#12
101
102Closes #392
103
104BREAKING CHANGE:
105
106 Breaks foo.bar api, foo.baz should be used instead
107```
108
109查看具体[文档](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit)
110
111## 发布管理
112
113data-set 基于 [semver] 语义化版本号进行发布。
114
115`master` 分支为当前稳定发布的版本。
116
117- 直接从 `master` 切出开发分支
118- 所有 API 的废弃都需要在当前的稳定版本上 `deprecate` 提示，并保证在当前的稳定版本上一直兼容到新版本的发布。
119
120### 发布策略
121
122每个大版本都有一个发布经理管理（PM），他/她要做的事情
123
124#### 准备工作：
125
126- 建立 milestone，确认需求关联 milestone，指派和更新 issues。
127
128#### 发布前：
129
130- 确认当前 Milestone 所有的 issue 都已关闭或可延期，完成性能测试。
131- 发起一个新的 [Release Proposal MR]，按照 [node CHANGELOG] 进行 `History` 的编写，修正文档中与版本相关的内容，commits 可以自动生成。
132 ```bash
133 $ npm run commits
134 ```
135- 指定下一个大版本的 PM。
136
137#### 发布时：
138
139- 将老的稳定版本（master）备份到以当前大版本为名字的分支上（例如 `1.x`），并设置 tag 为 {v}.x`（ v 为当前版本，例如 `1.x`）。
140- 发布新的稳定版本到 [npm]，并通知上层框架进行更新。
141- `npm publish` 之前，请先阅读[『我是如何发布一个 npm 包的』]。
142
143
144[semver]: http://semver.org/lang/zh-CN/
145[Release proposal MR]: https://github.com/nodejs/node/pull/4181
146[node CHANGELOG]: https://github.com/nodejs/node/blob/master/CHANGELOG.md
147[npm]: http://npmjs.com/
148[『我是如何发布一个 npm 包的』]: https://fengmk2.com/blog/2016/how-i-publish-a-npm-package