Stacks Core 项目版本发布流程详解

Stacks Core 项目版本发布流程详解

平台支持情况

Stacks Core 项目支持多种操作系统平台，以下是详细的平台支持矩阵：

| 平台类型 | 支持状态 | |-----------------------|-------------------------------------| | Linux 64位系统 | ✅ 完全支持 | | MacOS 64位系统 | ✅ 完全支持 | | Windows 64位系统 | ✅ 完全支持 | | MacOS Apple Silicon | ⚠️ 提供构建但不保证测试 | | Linux ARMv7架构 | ⚠️ 提供构建但不保证测试 | | Linux ARM64架构 | ⚠️ 提供构建但不保证测试 |

版本发布策略

常规发布周期

Stacks Core 采用月度发布周期，新功能会按计划每月发布一次。开发分支包含了即将发布的新特性，虽然经过基本测试，但相比主分支和正式发布版本，其稳定性稍逊一筹。

热修复机制

对于影响网络正常运行的关键问题，项目采用热修复机制。根据问题严重程度分为三个优先级：

1. 高优先级：可能导致全网服务中断的问题，如某些无效交易导致节点停止处理请求或意外关闭的情况。
2. 中优先级：可能导致矿工资金浪费的问题。
3. 低优先级：仅影响单个节点服务的问题。

版本号规范

Stacks Core 采用五段式版本号：X.Y.Z.A.n

• X (主版本号)：仅在重大网络升级时变更（如类似Stacks 3.0的重大更新）
• Y (共识破坏性变更)：包含破坏共识的变更时递增
• Z (需要重置链状态的变更)：类似语义化版本中的MAJOR
• A (引入新功能的变更)：类似语义化版本中的MINOR
• n (补丁和热修复)：类似语义化版本中的PATCH

可选地，版本号后可附加预发布标识符，如-rc1表示第一个发布候选版本。

非共识破坏性发布流程详解

1. 发布时机选择

发布应避开准备阶段，建议在新Stacking周期开始前至少24小时完成发布。

2. 版本准备阶段

1. 确定版本号：根据变更性质确定版本号增量
2. 创建发布分支：从开发分支创建release/X.Y.Z.A.n格式的分支
3. 标记阻塞问题：为影响发布的PR/Issue添加X.Y.Z.A.n-blocker标签

3. 测试验证

1. 区块重放测试：使用现有链状态进行完整重放测试
2. 同步测试：从创世区块开始完整同步测试

4. 代码整合

1. 如有必要，从开发分支挑选提交到发布分支
2. 创建特性分支进行变更
3. 合并特性分支到发布分支

5. 更新文档

1. 更新CHANGELOG文件，详细记录所有变更
2. 同步更新versions.toml中的版本信息
3. 分类整理所有PR到Added/Changed/Fixed章节

6. 构建与测试

1. 手动触发CI工作流构建发布候选版本
2. 通知生态参与者进行测试
3. 根据测试反馈修复问题并迭代发布候选版本

7. 正式发布

1. 确认最终发布候选版本无重大问题
2. 移除预发布标记
3. 通过官方渠道发布公告

8. 分支合并

1. 将发布分支合并到主分支
2. 将发布分支合并回开发分支

共识破坏性发布特别说明

共识破坏性发布基本流程与非共识破坏性发布相同，但需特别注意：

1. 预留足够时间进行创世区块同步测试
2. 明确新共识规则的激活高度
3. 提供更长的过渡期让网络参与者升级

最佳实践建议

1. 测试环境验证：所有发布候选版本应在测试网充分验证
2. 版本兼容性：注意检查依赖组件的版本兼容性
3. 文档完整性：确保发布说明和变更日志完整准确
4. 回滚计划：重大更新应准备回滚方案

通过这套严谨的发布流程，Stacks Core项目确保了网络升级的平稳性和可靠性，为整个生态系统的健康发展提供了坚实基础。