发布流程

对 Hummingbot 和 Hummingbot Gateway 代码库的更改通过拉取请求进行，这些请求在合并到代码库之前需经过全面的工程和质量保证审查，由基金会协调。

仅以下拉取请求将被审查：

• 已批准的提案：已批准的 PRP 及通过 HIP 批准申领赏金的拉取请求
• 错误修复：针对现有错误的修复

拉取请求状态看板¶

Hummingbot 基金会维护一个Github 看板，您可以在其中查看所有活跃拉取请求的状态，包括正在进行的 PRP、错误修复、正在审查等。

审查流程¶

虽然通过 HBOT 投票批准意味着社区希望将该修复或改进加入代码库，但拉取请求仍需经过一系列自动和人工检查，以确保新代码：* 不与其他代码库部分发生冲突或引发问题 * 不引入安全风险 * 不存在合并冲突 * 包含手动测试、文档，并符合代码质量准则 * 通过自动化测试

基金会的质量保证（QA）和工程团队成员负责协调此流程，并得到社区成员（例如技术评审 DAO）的协助。

在拉取请求获得批准后，它将经历以下开发周期：

分支¶

Hummingbot 代码仓库有三个主要分支，与每月发布的开发周期相关：

开发分支¶

所有希望合并到 master 分支的拉取请求必须先提交到开发分支。它们会先从 development 推送到 staging，然后再合并到 master。只有当存在与之相关的已批准 PRP 时，针对 development 分支的拉取请求才会被合并到 staging。

预发分支¶

staging 由基金会 QA 团队使用，用于在将代码变更合并到 master 或 main 分支之前进行全面测试。

master 或 main¶

master 是主要发布分支，包含 Hummingbot 软件客户端的最新稳定版本，并每月发布一次。

Hummingbot Gateway 的 main 分支具有相同的作用。