Kratos 社区希望能够得到广大开发者的帮助,所以希望您在要提 issue 或者 pull request 之前花几分钟来阅读一遍这篇指南。
Kratos 使用 Github Issues 来管理问题。 如果您希望提交 bug 报告或帮忙修复 bug 时,请先确保已经搜索过已有的 issues 和 pull requests 并且阅读了我们的 常见问题。
提交 bug 报告时,请使用我们提供的 issue 模板,清楚地描述遇到的问题和复现方式,如果方便,最好是可以提供一个最小复现仓库。
为了准确的区分用户提出的需求是否为大多数用户的需求或合理需求,分为 提案流程、向社区征集意见、社区采纳提案,作为新功能实现 这三个步骤来进行。
提案流程为了尽可能的简单,将流程分为 Feature、Proposal 和 PR 三个阶段,其中 Feature、Proposal 为 issue,PR 为具体的功能实现。具体流程如下:
如果您从未在 Github 上提交过代码,请跟随如下步骤:
注意在您提交 PR 请求时首先保证代码使用了正确的编码规范,并有完整的测试用例,提交 PR 的信息中最好关联相关的 issue,以减轻审核人员的工作负担。
遵循 Conventional Commits 来规范化 commit message
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
提交的 commit 类型主要有以下几种:
提交的代码修改的代码文件范围:
用简短的话语清晰的描述提交的代码做了什么事。
补充说明,用于描述原因、目的、实现逻辑等可以省略。
fix: The log debug level should be -1
refactor!(transport/http): replacement underlying implementation
fix(log): [BREAKING-CHANGE] unable to meet the requirement of log Library
Explain the reason, purpose, realization method, etc.
Close #777Doc change on doc/#111BREAKING CHANGE: Breaks log.info api, log.log should be used instead
Release 时可以使用 kratos changelog dev
命令生成 Release 说明,工具会筛选出来从上一次 Release 到现在的所有提交信息,然后根据提交的分类不同,主要汇总成以下几类:
通过 kratos changelog dev
生成的文本,只需简单修改即可作为 Release 版本发布的说明.
### New Features- feat(cmd): add kratos changelog command (#1140)- feat(examples): add benchmark example (#1134)- feat: add int/int32/Stringer support when get atomicValue (#1130)### Others- add form encoding (#1138)- upgrade otel to v1 rc1 (#1132)- http stop should use ctx (#1131)