第一章 总则¶
第一条 制定依据
本章程依据《量潮科技基本章程》和《量潮科技研发运维章程》制定，旨在建立公司数字资产版本发布的标准化管理规则。
第二条 目的
为建立统一的版本发布流程，确保发布过程可追溯、可回滚、可审计，特制定本章程。
第三条 适用范围
本章程适用于公司所有数字资产的版本发布活动，包括代码库、文档站、数据档案等。
第四条 定义
（一）发布，指对数字资产创建可追溯的版本标识（Git tag）并推送至远程仓库，作为该资产的稳定基线。
（二）发布记录，指记录版本状态变更的不可变事件日志。
（三）发布状态，指版本所处的生命周期状态。
第二章 版本号¶
第五条 版本号规范
版本号遵循语义化版本规范：主版本.次版本.修订号。
（一）修订号：Bug 修复、文档修正、配置调整等不改变接口的变更，小步快跑，随发随加。
（二）次版本：新增功能或内容，不破坏向后兼容性，按里程碑升级。
（三）主版本：不兼容的 API 变更、重大架构调整。
第六条 版本号格式
版本号须符合 vX.Y.Z 格式（如 v0.6.12），不得缺少前缀 v，不得包含空格或特殊字符。版本号是发布的唯一业务标识键。
第三章 发布状态机¶
第七条 状态定义
发布的版本共有四种状态：
（一）Staged（待发布）：版本已准备就绪，标记为待发布状态。
（二）Published（已发布）：版本已完成 tag 创建、推送和 GitHub Release 创建。
（三）Cancelled（已取消）：版本在待发布状态下被取消，不进入发布流程。
（四）Retired（已退役）：已发布的版本被标记为退役，表示不再推荐使用。
第八条 状态转换
发布的版本只能在以下状态之间转换：
（一）Staged ← Published：从待发布转为已发布。须同时创建 Git tag、推送至远程仓库、创建 GitHub Release。
（二）Staged ← Cancelled：从待发布转为已取消。须清理已创建的远程 tag 和 GitHub Release。
（三）Published ← Retired：从已发布转为已退役。退役是终态，从 Retired 出发的任何转换均为非法。
（四）Cancelled ← Staged：取消状态的版本可重新进入待发布。
第九条 非法转换
禁止以下状态转换：
（一）从 Retired 状态出发的任何转换。
（二）Published 直接转为 Cancelled。
（三）Staged 直接转为 Retired。
第四章 发布流程¶
第十条 发布前置条件
每次发布前须完成以下前置检查：
（一）CHANGELOG 已更新至最新版本号，变更记录完整。
（二）所有涉及本次发布的变更已提交并推送至远程仓库。
第十一条 发布步骤
发布应按以下步骤执行：
（一）标记版本为待发布状态。
（二）确认版本信息无误后执行发布操作。
（三）发布操作自动创建 Git tag、推送至远程仓库、创建 GitHub Release。
第十二条 发布后操作
发布完成后，须在父仓库（quanttide-tech → quanttide）中更新对应的子模块引用指针。子模块发布后父仓库指针的更新应视为发布流程的组成部分。
第五章 发布纪律¶
第十三条 CHANGELOG 先行
每次发布必须在创建 tag 之前先更新 CHANGELOG。禁止先打 tag 后补 CHANGELOG。
第十四条 tag 与提交一致性
发布的 Git tag 必须指向包含 CHANGELOG 更新的提交。发布后不得对已推送的 tag 进行修改或删除。
第十五条 发布记录完整
发布操作应当产生不可变的发布记录。取消操作也应当产生记录，确保每次发布尝试有独立身份。
第十六条 外部操作失败处理
发布过程中涉及的外部操作（tag 创建、推送、GitHub Release 创建）任一失败时，应当回滚已执行的 tag 操作。回滚后发布状态不自动回退，须重新执行发布。
第六章 附则¶
第十七条 章程效力
本章程经公司治理机构审议通过，自发布之日起生效。
第十八条 解释权
本章程之解释，应遵循可追溯之基本原则。各项条文不得被解释为阻碍合理的发布流程创新或为发布设置不必要的障碍。