跳到主要内容

开发者手册

准备​

TIP

本文是为应用程序开发者所编写的，如果你对曙光的内部原理感兴趣，或希望参与到曙光的开发中来，那么可前往阅读 曙光详细介绍 来获取更多曙光的相关信息。

在您开始修改曙光源码之前，先从下述地址中获取相关代码

壳工程管理方式目标

项目采用 壳工程 的方式来管理多个仓库

在壳工程中，你可以明确知道多个仓库该如何组合使用。

管理 Issues​

我们使用 Github Issues 来跟踪公共错误和功能请求。

  1. 搜索已知问题
    • 请搜索现有问题查看是否已提交任何类似问题或功能请求，避免重复提交。
  2. 报告新问题
    • 提交问题时尽可能提供充分的信息，例如问题的详细描述、屏幕截图或视频、崩溃日志以及代码块等等。
  3. 交流讨论
    • 欢迎加入我们的微信交流群，任何相关问题可以随时在群里讨论。

讨论​

所有的问题讨论，都可以在 discussions 中

代码提交​

我们非常欢迎您共同参与项目的开发工作，让曙光变得更好。

分支管理​

主要有3个分支：

  1. master 分支
    1. 它是最新的（预）发布分支。 我们使用 master 作为标签，版本号为 1.1.0、1.2.0、1.3.0...
    2. 不要在 master 分支上提交任何 PR。
  2. dev 分支
    1. 这是固定的开发分支，我们会定期全面测试dev分支，通过测试后将其合并到 master 分支并在下个版本生效。
    2. 版本号为1.3.1、1.3.2、1.3.3...
  3. feature/*
    1. 这是提交 PR 的个人分支，命名不是强制的，只要不和其他分支产生冲突即可
    2. 提交的PR在经过CodeReview以及单元测试后, feature/* 将会合并到 dev 分支并在下个小版本生效。
    3. feature/* 的后缀命名您可以自由定义，比如 feature/zhangsan
    4. 建议您在 feature/* 分支提交 bugfix 或功能 PR。

一般错误修复或功能请求提交给 feature/* 分支。 经过 Code Review 和单元测试后，我们会将它们合并到 dev 分支并在下个小版本生效。 dev分支会定期进行全面测试，测试通过后会合并到master分支

master
 ↑
dev                   ←  定期全面测试
 ↑ 
feature/fix_zhangsan  ←  PR，code review + 单元测试

Release 发布​

所有工程，均采用 tag 三位数字的方式来进行发布，比如 1.0.0, 1.0.3, 1.3.2, 2.x.x 等

  1. 第一位：重大修改，一般是我们大型重构或者能力上线的版本
  2. 第二位：比较重要的修改，一般需要指定其他端来配合才可以使用
  3. 第三位：向前兼容，可以跟目前所有其他端直接配合使用

tag只能打在 master 分支上

文档发布​

  • 除非重大修改之外，其他能力均直接在文档中修改即可
  • 但是比较重要的修改，需要在文档中注明，该能力从哪个tag开始生效

提交 PR​

按照如下步骤提交 PR：

  1. 从 dev fork 并创建您的分支；
  2. 如果您更改了 API，请更新代码或文档；
  3. 将版权声明添加到您添加的任何新文件的顶部；
  4. 检查你的代码 lints 和 checkstyles；
  5. 反复测试您的代码；
  6. 往 dev 分支提交您的 pull request。

License​

给本项目提交源码表示您同意本项目的 LICENSE