嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载PX4 开源飞控采用一套完整的「基于分支 标签演进」的发布流程从创建发布分支、Alpha/Beta/RC 多阶段验证到 Stable 发布、S3 固件分发与 GitHub Release 自动化均有明确的治理规则。本文以 docs/en/releases/release_process.md 为骨架结合仓库内真实的工作流文件.github/workflows/build_all_targets.yml、.github/workflows/ros_integration_tests.yml与发布记录docs/en/releases/完整讲解维护者如何推进一个 PX4 版本从立项到发布的每一步——读完你可以直接照此流程操作分支、打 GPG 签名标签、组织投票并触发自动化发布。总体概览分支模型与发布节奏PX4 采用基于分支branch-based的发布工作流核心分支有三类分支作用release/X.Y如release/1.18、release/2.0某个具体版本的活跃开发分支变更在此合并并经过测试stable指向最新稳定版发布标签每次发布后重置beta供飞行测试人员验证发布候选版本RC目标发布周期约为6 个月尽力而为。实际节奏取决于测试结果与维护者可用时间官方一直致力于缩短该周期。这一节奏在仓库中可以直接印证docs/en/releases/index.md 罗列了从 v1.12 到 v1.18 的连续发布记录其中 main.md 对应下一个大版本v2.0 或更晚的变更累积页。发布标签演进阶段发布分支会经历以下标签阶段每个阶段对合并内容有严格限制阶段示例分支状态可合并内容Alphav1.18.0-alpha1开放修复仅限 Bug 修复与回归修复Betav1.18.0-beta1开放修复仅限 Bug 修复与回归修复RCv1.18.0-rc1冻结什么都不合除非否决投票通过Stablev1.18.0开放修复Bug 修复与回归修复用于补丁版本关键规则新功能永不合入发布分支。一旦发布分支从main创建后续只接受 Bug 修复与回归修复新功能必须瞄准main留待下一个发布周期。这一「分支即防火墙」的设计保证了发布分支上代码行为的可预测性是飞行安全软件质量治理的基础。开启新发布周期新发布周期在 Stable 发布后立即开始。在每周社区问答会议上审批 Stable 发布时会同时进行两次投票投票发布当前版本——批准 Stable 版本对外发布投票决定下一版本号——确定下一版本号如 v1.18 或 v2.0。每周社区问答会议原「Dev Call」的议程、时间与参与方式见 docs/en/contribute/dev_call.md——会议每周三 17:00CET举行面向所有社区成员开放发布投票正是在这个场合进行。分支创建前的发布说明准备发布说明是增量累积的随着变更合入main发布说明会同步累积在 docs/en/releases/main.md 中。创建发布分支前需要完成以下准备工作将main.md重命名为版本专属文件例如docs/en/releases/1.18.md将新文件加入SUMMARY.md与releases/index.md仓库中的 docs/en/SUMMARY.md 正是按此结构组织 Releases 章节将main.md重置为干净模板供下一发布周期继续累积核验所有已合入贡献对应的文档是否完整搜索所有main (planned for:字样并替换为已确定的发布版本——例如把Badge typetip textmain (planned for PX4 v1.xx /替换为Badge typetip textPX4 v1.xx /。注意一旦下一版本号确认badge 可以使用第二种形式如Badge typetip textPX4 v1.18 /搜索所有Badge typewarning textExperimental /对于已被视为核心/稳定的功能移除该 Experimental 标记。提示社区成员被鼓励在变更合入main时就同步记录文档变更这样既分散了文档工作量又能保证变更在记忆犹新时被记录下来。仓库中 1.18.md 与 main.md 的分节结构Read Before Upgrading / Major Changes / Upgrade Guide / Hardware Support / Common / Control / Safety / Estimation / Sensors / Simulation / MAVLink / RC 等就是这套「随时代入」规范的直接产物。创建发布分支确定下一版本号后在 PX4-Autopilot 及其配套仓库中从main创建新发布分支# PX4-Autopilot git checkout main git pull git checkout -b release/1.18 git push origin release/1.18配套仓库也必须创建对应的发布分支PX4/px4_msgsPX4 的 ROS 2 消息定义仓库仓库内 msg/ 目录与px4_msgs_old/正是其消息来源Auterion/px4-ros2-interface-libROS 2 接口库创建配套分支后还需要在发布分支上修改 ROS 集成测试工作流让测试从匹配的发布分支克隆px4-ros2-interface-lib- git clone --recursive https://github.com/Auterion/px4-ros2-interface-lib.git git clone --recursive --branch release/1.18 https://github.com/Auterion/px4-ros2-interface-lib.git警告发布分支一旦创建只接受 Bug 修复与回归修复所有新功能开发继续在main上进行。创建首个 Alpha 标签发布分支创建后立即创建第一个 alpha 标签标记发布周期正式开始# 在新建的发布分支上 git checkout release/1.18 # 创建签名 alpha 标签 git tag -s v1.18.0-alpha1 -m v1.18.0-alpha1 git push origin v1.18.0-alpha1后续随修复合入可以继续创建 alpha 标签如v1.18.0-alpha2、v1.18.0-alpha3。发布全流程 14 步详解1. 审查与合并 PRAlpha 阶段Alpha 阶段需要审查指向发布分支的 PR按项目贡献指南审查 PR只合并 Bug 修复与回归修复新功能必须瞄准main而非发布分支随修复合入创建更多 alpha 标签如v1.18.0-alpha2。2. Alpha 测试Dronecode 测试团队由 Ascend Engineering 提供Dronecode Silver 会员使用以下手段对 alpha 构建进行首轮飞行测试PX4 指南中记录的测试卡——即标准化的飞行测试清单覆盖多旋翼MC_01手动模式、MC_02全自主、MC_03自动手动混合、MC_04失效保护测试等与固定翼FW_01手动模式、FW_02全自主等系列覆盖受支持飞控与机型的硬件矩阵。Alpha 测试的核心目标是尽早发现回归与阻塞问题。Alpha 阶段结束进入 Beta的条件核心硬件矩阵上所有测试卡全部通过无关键或高严重级别失败所有已识别回归都有修复合入或已分诊为非阻塞已包含变更的发布说明与文档完整。3. 创建 Beta 标签满足上述 Alpha 退出标准后创建第一个 beta 标签# 在发布分支上 git checkout release/1.18 git pull # 创建签名 beta 标签 git tag -s v1.18.0-beta1 -m v1.18.0-beta1 git push origin v1.18.0-beta14. Beta 测试Beta 构建发布给更广泛的社区验证。与 Alpha仅由 Dronecode 测试团队在核心硬件矩阵上进行不同Beta 测试聚焦于社区测试——Beta 构建对社区成员开放可自备硬件与机型配置测试扩展硬件覆盖——在核心测试矩阵之外的硬件与配置上进行测试真实飞行场景——长航时飞行、任务测试以及标准测试卡未覆盖的边界情况。Beta 期间持续进行审查并合并仅限 Bug 修复与回归修复随修复合入创建更多 beta 标签如v1.18.0-beta2、v1.18.0-beta3。5. 创建发布候选RC标签Beta 阶段结束的条件至少一个 beta 标签周期内没有新的关键/高严重级别问题报告所有 Beta 报告回归都有修复合入或已分诊为非阻塞。满足 Beta 退出标准后创建第一个 RC# 在发布分支上 git checkout release/1.18 git pull # 创建签名 RC 标签 git tag -s v1.18.0-rc1 -m v1.18.0-rc1 git push origin v1.18.0-rc1警告分支自此冻结除非否决投票通过否则不再合入任何 PR。提示所有标签必须使用GPG 签名。只有注册了 GPG 密钥的维护者才能创建发布标签请确保你的账号已配置 GPG 签名。6. RC 测试与分支冻结RC 测试期间发布分支处于冻结状态默认不合入任何 PR测试聚焦 Stable 发布前的最终验证发现的任何问题都会被记录并评估。关键修复的否决投票Veto Vote如果 RC 测试期间发现必须在发布前修复的关键问题在每周社区问答会议上提出该问题陈述该修复为何是关键性的维护者投票决定是否合入该修复若通过合入修复并创建新的 RC 标签如v1.18.0-rc2。7. 发布投票发布投票在每周社区问答会议上进行汇报发布状态与测试结果投票 1核心维护者投票决定是否发布该版本投票 2决定下一发布版本的名字/编号。8. 创建并推送发布标签投票通过后创建最终发布标签# 在发布分支上 git checkout release/1.18 git pull # 创建签名发布标签 git tag -s v1.18.0 -m v1.18.0 git push origin v1.18.09. 更新 Stable 分支将stable分支重置指向新的发布标签git checkout stable git reset --hard v1.18.0 git push --force origin stable警告这是强制推送会重写stable分支历史。执行前务必确认指向了正确的标签。10. GitHub Release自动化推送版本标签后build_all_targets.yml GitHub Actions 工作流会自动执行为所有受支持目标构建固件将固件产物上传到 AWS S3存入Firmware/vX.Y.Z/并更新Firmware/stable/创建包含所有.px4固件文件的 GitHub草稿发布draft release。从工作流文件头部注释可以看到完整的 S3 目录语义该工作流现运行在 Dronecode/PX4 的 AWS 账号上触发条件S3 上传位置说明标签v1.16.1v1.16.1/仅版本归档标签v1.17.0-beta1v1.17.0-beta1/仅版本归档预发布分支mainmaster/供 QGC 兼容的最新 main 构建分支stablestable/QGC 稳定固件分支betabeta/QGC 预发布固件分支release/**无仅构建CI 验证Pull Request无仅构建CI 验证一个值得注意的设计细节版本标签不会上传到stable/或beta/只有对应分支的推送才控制这些目录——这防止了预发布标签意外覆盖稳定固件issue #26340也避免了标签与分支构建之间的竞态。此外工作流为所有版本标签创建draftGitHub Release含-alpha/-beta/-rc后缀的自动标记为预发布CAN 节点固件以target.uavcan.bin与target_canbootloader.bin附加树内 bootloader 目标以target_bootloader.bin裸 SWD 镜像附加。从 1.18 发布说明 还可以看到每个固件构建会自动生成 SPDX 2.3 软件物料清单SBOM并作为.sbom.spdx.json产物一并附加可通过PX4_SBOM_DISABLE1关闭。11. 发布 GitHub Release在 GitHub 上编辑草稿发布添加主要变更的简要描述链接到文档中的完整发布说明例如releases/1.18.md即 docs/en/releases/1.18.md正式发布Publish。12. 完善文档审阅并完善整个发布周期中逐步累积的发布说明确保所有值得记录的变更、新功能与升级指南都已成文审阅完整性与准确性参照现有发布说明确认格式符合预期。13. 宣布发布通过官方渠道宣布发布PX4 Discuss 论坛PX4 Discord社交媒体Twitter/X、LinkedInDronecode 简报newsletter14. 开始下一发布周期发布完成后立即启动下一周期从main创建新发布分支见上文「创建发布分支」为新版本创建 alpha 标签为下一版本创建初始文档重命名并准备项目板见下文「项目板管理」。补丁发布Point ReleasesStable 发布后发布分支会重新开放接受 Bug 修复与回归修复以支撑补丁版本如v1.18.1。补丁发布流程将 Bug 修复与回归修复合入发布分支如需要测试创建 beta 标签如v1.18.1-beta1创建 RC 标签做最终验证如v1.18.1-rc1测试与投票后为补丁版本打标签更新stable分支并发布。项目板管理PX4 发布项目板PX4 Release Project Board在多个发布周期之间复用用于跟踪当前版本的 issue 与 PR每个发布周期会重命名并复用。发布之后版本发布后重命名项目板以反映下一版本号例如「v1.17 Release」→「v1.18 Release」审阅剩余条目关闭不再相关的条目将未完成且应顺延到下一版本的条目移入下一周期移除被降级或无限期推迟的条目更新项目板描述以反映新的发布目标。仓库内的佐证与延伸阅读以上流程在仓库中均有可验证的落地证据发布记录产物docs/en/releases/ 下的1.12.md–1.18.md与main.md正是「main.md 累积 → 发布时重命名为版本文件 → 重置模板」机制的长期运行结果docs/en/SUMMARY.md 的 Releases 章节结构含当前main (alpha)、v1.18 (beta)、1.17 (stable)状态标注与标签演进阶段一一对应发布说明写作规范1.18.md 与 main.md 展示了统一的章节模板Major Changes、Upgrade Guide、Hardware Support、Common/Control/Safety/Estimation/Sensors/Simulation 等分类并大量使用main (planned for ...)/Experimentalbadge 与 PR 引用——这正是发布前第 5、6 步清理工作的对象自动化发布.github/workflows/build_all_targets.yml 完整实现了「推送版本标签 → 构建全部目标 → S3 上传 → 创建 draft release」链路配套仓库协同.github/workflows/ros_integration_tests.yml 是发布分支创建时必须适配 clone 分支的工作流.github/workflows/sync_to_px4_msgs.yml、.github/workflows/tag_px4_msgs_from_px4_release_tag.yml 等则印证了发布周期中消息库与接口库的同步机制飞行测试规范docs/en/test_and_ci/test_flights.md 定义了 Alpha 阶段执行的标准化测试卡MC_01至MC_11、FW_01/FW_02等具体卡片文档位于 docs/en/test_cards/ 下。结语PX4 的发布流程可以概括为一条清晰的纪律链新功能永远瞄准main发布分支只收修复标签从 Alpha 到 Beta 再到 RC 逐级收敛RC 冻结后一切变更需投票豁免Stable 标签触发全自动的固件构建、S3 分发与草稿 Release 创建。这套流程将「版本质量的把关」分散到 Dronecode 测试团队、社区飞行测试者与核心维护者三方并用 GPG 签名标签、分支冻结与项目板管理保证过程可审计、可追溯。理解并遵循这套流程是 PX4 每个版本得以安全、准时落地的基础也是所有维护者与深度贡献者必须掌握的协作契约。赞分享嵌入式物联网机器人自动驾驶智能硬件【免费下载链接】PX4-AutopilotPX4 Autopilot Software项目地址https://gitcode.com/gh_mirrors/px/PX4-Autopilot点击查看免费下载相关推荐QGroundControl 发布与分支管理流程详解从语义版本号到 Stable 分支与补丁发布QGroundControl 发布与分支管理流程详解从语义版本号到 Stable 分支与补丁发布 导读 本文基于 QGroundControlQGC官方开无人机智能硬件libsecp256k1 发布流程全解从版本宏管理到 GPG 签名打标签libsecp256k1 发布流程全解从版本宏管理到 GPG 签名打标签 libsecp256k1 是 Dogecoin 核心仓库中负责 ECDSA 签名与区块链解析 Terraform Core 的 GitHub Bug 分诊与标签治理流程从 Bug 报告到修复发布解析 Terraform Core 的 GitHub Bug 分诊与标签治理流程从 Bug 报告到修复发布 BUGPROCESS.md 是 TerraformIaCCLI基础设施云原生DevOps上一篇Rivet Actors 的 RunnerConfigsUpsert API 与 RunnerConfigsUpsertResponse 模型解析下一篇Node.js 11.10.1Current安全发布深度解析CVE-2019-5737 Slowloris keep-alive DoS 修复与 HTTP 超时防御机制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考