区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载导读Monero 采用定时软硬件升级硬分叉机制持续推进共识规则演进每一次网络升级都是一次跨代码、跨生态的高风险工程。本文以仓库内 docs/RELEASE_CHECKLIST.md 这份官方发布检查清单为骨架结合 硬分叉表、检查点机制、版本定义模板 等源码完整拆解从审计、硬件钱包集成、分叉高度设定、生态通知、Release 分支代码变更、Testnet/Stagenet 验证到最终发布公告的每一个环节。读完本文你将掌握一次 Monero 硬分叉版本从代码冻结到全网公告的全部步骤、涉及的仓库文件与命令行操作并理解检查点校验、可复现构建等核心环节的底层实现原理。一、发布清单在 Monero 发布流程中的定位Monero 的版本发布与网络升级是绑定进行的。根据 README.md 的说明Monero 使用定时软件/网络升级hard fork机制来引入新功能软件升级在代码库中开发并实现新功能网络升级则在修改共识规则的软件升级发布时同步发生且升级所需的软件会在计划升级日期之前提供。README 中以表格形式维护了每个升级的块高度 / 日期 / Fork 版本 / 最低 Monero 版本 / 推荐 Monero 版本 / 详情并注明在计划软件升级前大约三个月会从 master 创建带新版本号标签的分支修复 bug 的 PR 应同时提交到 master 与新的 release 分支需要大量评审与测试的改动一般是优化与新特性不应进入 release 分支。docs/RELEASE_CHECKLIST.md正是执行这条流程的操作手册它将整个发布过程组织为 9 个相互依赖的阶段代码与安全审计Ledger / Trezor 硬件钱包集成分叉高度设定与公告通知钱包、交易所、支付处理器、矿池Release 分支创建与代码变更版本号、README、检查点Testnet 分叉与验证Stagenet 分叉与验证CLI / GUI 可复现构建与发布最终发布公告清单采用 Markdown 复选框- [ ]形式每一项都可勾选天然适合作为 PR 或 issue 模板逐项跟进。二、第一阶段代码与安全审计发布的第一步不是写代码而是验证代码Security audit安全审计针对新引入的共识规则、密码学实现如新签名方案、环签名变体与 RPC 面进行独立安全审查。Monero 对共识代码的变更极其敏感任何可导致链分裂或资金风险的缺陷都必须在此阶段暴露。Code audit代码审计对代码质量、边界条件、资源管理与向后兼容性做系统性评审。结合 README.md 中需要大量评审与测试的改动不应进入 release 分支的原则审计重点是确认进入 release 分支的只有 bug 修复与共识必需的改动。审计结论将直接决定后续阶段是否启动是整条清单的门禁。三、硬件钱包集成Ledger 与 TrezorMonero 的用户大量依赖硬件钱包保管密钥每次共识规则变化分叉都会影响硬件钱包的签名与交易构造逻辑因此清单将硬件钱包集成单列为独立阶段。3.1 Ledger 集成检查项Ledger notified通知 Ledger 团队Pull request made against Monero codebase (if needed)如需要向 Monero 代码库提交 PRPull request merged into Monero codebase (if needed)如需要合入 PRLedger app integration codedLedger 应用集成编码Ledger Monero app update availableLedger Monero 应用更新上线仓库中 Ledger 支持的核心代码位于 src/device/其中 device_ledger.cpp 实现了通过 HID 与 Ledger 设备通信的完整逻辑device_io_hid.cpp 封装了底层 HID 传输层对应构建依赖见 cmake/FindHIDAPI.cmake。3.2 Trezor 集成检查项Trezor notifiedPull request made against Monero codebase (if needed)Pull request merged into Monero codebase (if needed)Trezor firmware update codedTrezor 固件更新编码Trezor firmware update availableTrezor 固件更新上线Trezor 支持位于 src/device_trezor/其中 device_trezor.cpp 与 device_trezor_base.cpp 实现设备交互src/device_trezor/trezor/ 目录内包含与 Trezor 固件通信的 protobuf 消息定义*.proto与序列化代码。构建期对 Trezor 的支持检测见 cmake/CheckTrezor.cmake。实践要点硬件钱包的 PR 必须在 Release 分支冻结前合入且固件/应用的更新要先于或同步于主软件发布否则分叉后硬件钱包用户将无法正常交易。四、设定分叉高度并对外公告分叉高度是共识变更的触发坐标。仓库中的硬分叉参数统一维护在 src/hardforks/hardforks.cpp其数据结构定义于 src/hardforks/hardforks.hstruct hardfork_t { uint8_t version; // 协议版本号 uint64_t height; // 触发分叉的区块高度 uint8_t threshold; // 升级投票阈值 time_t time; // 最终确定的激活时间戳 hardfork_t(uint8_t version, uint64_t height, uint8_t threshold, time_t time) : version(version), height(height), threshold(threshold), time(time) {} };例如主网历史分叉条目节选// version 6 starts from block 1400000, which is on or around the 16th of September, 2017. { 6, 1400000, 0, 1503046577 }, // version 15 / 16同一时间戳相邻高度触发两段升级 { 15, 2688888, 0, 1656629117 }, { 16, 2689608, 0, 1656629118 },清单要求分叉高度确定后通过三个渠道向社区公告Twitter announcementReddit announcementGetmonero.org announcement公告需明确分叉块高度与预计日期、用户需要升级到的最低版本并提醒服务商钱包、交易所、矿池提前升级节点。注意hardfork_t中的time字段是最终确定时间fork 不再有投票机制后threshold为 0实际触发以height为准这与 README fork 表Software upgrade block height列一一对应。五、生态通知钱包、交易所、支付处理器与矿池共识升级影响所有依赖节点与交易格式的服务方清单要求主动逐一通知而非等对方发现5.1 通知钱包13 家MyMoneroCoinomiExa WalletWookey WalletX WalletGuardaZelCoreCake WalletMonerujoEdge WalletExodusXMRWalletFeather Wallet5.2 通知交易所依据 https://www.getmonero.org/community/merchants/#exchanges 维护的交易所清单逐一联系5.3 通知第三方支付处理器依据 https://www.getmonero.org/community/merchants/#payment-gateways 维护的网关清单逐一联系BTCPayServer5.4 通知矿池依据 https://miningpoolstats.stream/monero 上活跃的 Monero 矿池清单逐一联系实践要点通知内容应包含分叉高度、激活时间、最低节点版本、新增/变更的共识规则摘要以及必要的迁移指引。交易所与支付处理器通常需要停机升级与回归测试越早通知升级窗口越充裕。六、Release 分支创建与代码变更核心工程环节这是清单中技术含量最高的一节共 5 项代码变更全部有对应的仓库文件支撑。所有变更都应在从 master 拉出的 release 分支上完成参考 README.md 的分支策略。6.1 更新版本号与版本名清单Update src/version.cpp.in with new version AND new name (if necessary)版本定义模板位于 src/version.cpp.inCMake 在构建时用实际配置替换...占位符后生成版本源码。当前仓库的版本信息如下#define DEF_MONERO_VERSION_TAG VERSIONTAG #define DEF_MONERO_VERSION 0.18.1.0 #define DEF_MONERO_RELEASE_NAME Fluorine Fermi #define DEF_MONERO_VERSION_FULL DEF_MONERO_VERSION - DEF_MONERO_VERSION_TAG #define DEF_MONERO_VERSION_IS_RELEASE VERSION_IS_RELEASE导出的全局变量被monerod、monero-wallet-cli等所有二进制共享MONERO_VERSION、MONERO_RELEASE_NAME、MONERO_VERSION_FULL、MONERO_VERSION_IS_RELEASE。发布时需将DEF_MONERO_VERSION改为新版本号如0.18.2.0若官方为本版本命名如 Fluorine Fermi 风格的化学元素代号同步更新DEF_MONERO_RELEASE_NAMEDEF_MONERO_VERSION_IS_RELEASE在正式发布构建中由 CMake 置为1开发构建为0。6.2 更新 README 的 fork 表清单Update README.md with new fork table entry (or at least update the Recommended Monero version)README.md 中的软件升级表以块高度 / 日期 / Fork 版本 / 最低版本 / 推荐版本 / 详情六列维护每个升级发布时需为本次分叉新增一行并更新该表的Recommended Monero version为本次发布版本让生态开发者一眼看清需要升级到什么版本。6.3 更新硬编码检查点清单Update src/checkpoints/checkpoints.cpp with a recent hardcoded checkpoint硬编码检查点用于快速同步与防回滚保护位于 src/checkpoints/checkpoints.cpp 的load_hardcoded_checkpoints主网部分以宏形式追加最新高度条目例如ADD_CHECKPOINT2(2720000, b19fb41dff15bd1016afbee9f8469f05aab715c9e5d1b974466a11fd58ecbb86, 0x3216b5851ddbb61);宏的三个参数分别是区块高度、区块哈希、累计难度十六进制。对应的方法签名定义在 src/checkpoints/checkpoints.hbool checkpoints::add_checkpoint(uint64_t height, const std::string hash_str, const std::string difficulty_str);硬编码检查点只增不删发布时追加当前链头附近的最新检查点即可。6.4 重新生成 checkpoints.dat清单Update src/blocks/checkpoints.dat with ./monero-blockchain-export --output-file checkpoints.dat --block-stop recent block height --blocksdat这是清单中唯一一条命令行操作用于从同步好的本地链导出预计算块哈希数据命令原型为./monero-blockchain-export --output-file checkpoints.dat --block-stop recent block height --blocksdat其中--output-file checkpoints.dat导出文件名--block-stop recent block height导出到哪个高度为止一般取接近链头的高度--blocksdat以 blocks.dat 格式输出。对应参数在 src/blockchain_utilities/blockchain_export.cpp 中定义const command_line::arg_descriptoruint64_t arg_block_stop {block-stop, Stop at block number, block_stop}; const command_line::arg_descriptorbool arg_blocks_dat {blocksdat, Output in blocks.dat format, blocks_dat};导出逻辑通过BlocksdatFile::store_blockchain_raw(...)完成见 src/blockchain_utilities/blocksdat_file.cpp导出结果直接落盘为 src/blocks/checkpoints.dat。6.5 更新预计算块哈希的校验值清单Update expected_block_hashes_hash in src/cryptonote_core/blockchain.cpp with checkpoints.dat sha256 hash节点在快速同步fast sync模式下会加载编译进二进制的checkpoints.dat并对其做完整性校验。校验常量与逻辑位于 src/cryptonote_core/blockchain.cpp受PER_BLOCK_CHECKPOINT编译宏保护#if defined(PER_BLOCK_CHECKPOINT) static const char expected_block_hashes_hash[] 2aea941d43024422a63f223c84b9d88d1f58d31e1f508c2d6d43cd637ba32d16; void Blockchain::load_compiled_in_block_hashes(const GetCheckpointsCallback get_checkpoints) { if (get_checkpoints nullptr || !m_fast_sync) { return; } ... if (m_nettype MAINNET) { // first check hash crypto::hash hash; if (!tools::sha256sum(checkpoints.data(), checkpoints.size(), hash)) { MERROR(Failed to hash precomputed blocks data); return; } MINFO(precomputed blocks hash: hash , expected expected_block_hashes_hash); ... if (hash ! expected_hash) { MERROR(Block hash data does not match expected hash); return; } }底层格式从load_compiled_in_block_hashes的解析代码可以还原checkpoints.dat前 4 字节为小端uint32_t块数nblocks随后是nblocks × (sizeof(crypto::hash) × 2)字节的数据每块两个 32 字节哈希。节点校验逻辑如下const uint32_t nblocks *p | ((*(p1))8) | ((*(p2))16) | ((*(p3))24); if (nblocks (std::numeric_limitsuint32_t::max() - 4) / sizeof(hash)) { ... return; } const size_t size_needed 4 nblocks * (sizeof(crypto::hash) * 2); if (checkpoints.size() ! size_needed) { ... }因此发布流程是先执行 6.4 的导出命令 → 计算新checkpoints.dat的 SHA-256 → 用该值替换expected_block_hashes_hash字符串。两者必须同步更新否则主网节点会打印Block hash data does not match expected hash并拒绝加载预计算块。提示检查点文件缺失时节点仍可正常启动load_checkpoints_from_json在文件不存在时返回true并提示 Blockchain checkpoints file not found但快速同步能力会退化因此不要遗漏该步骤。七、Testnet 与 Stagenet 分叉与验证正式发布前新共识规则必须在测试网与暂存网完整走一遍。7.1 Testnet 分叉与验证Testnet forkedTestnet testing/verificationLedgerTrezorRelease-specific testing针对本次发布特性的专项测试RPC testing / update RPC documentationRPC 测试并更新 RPC 文档7.2 Stagenet 分叉与验证Stagenet forkedStagenet testing/verificationLedgerTrezorRelease-specific testing测试网与暂存网的分叉参数分别维护在 src/hardforks/hardforks.cpp 的testnet_hard_forks[]与stagenet_hard_forks[]数组中hardfork_t结构与主网一致并在 src/hardforks/hardforks.h 中声明导出。三个网络的检查点 JSON 与 DNS 源也各自独立见 src/checkpoints/checkpoints.cpp 中checkpoints.moneropulse.*、testpoints.moneropulse.*、stagenetpoints.moneropulse.*三组 DNS 域。验证重点硬件钱包Ledger / Trezor在测试网完成全流程交易签名针对本次升级特性的专项测试如新的交易格式、新的环签名、新的费用算法RPC 接口行为变化要同步更新 RPC 文档相关命令定义见 src/rpc/core_rpc_server_commands_defs.h 与 src/wallet/wallet_rpc_server_commands_defs.h。八、可复现构建验证与 CLI / GUI 发布8.1 CLI 可复现构建验证CLI reproducible builds validatedMonero 通过 contrib/guix/ 提供基于 GNU Guix 的可复现构建环境核心描述文件为 contrib/guix/manifest.scm配套guix-attest、guix-verify、guix-clean等脚本配合 contrib/depends/ 的依赖锁定机制确保任何人在任何机器上构建出的二进制哈希一致。这一步为后续在官网公布hashes.txt提供可信依据。8.2 CLI 发布https://www.getmonero.org/downloads/ 更新下载页更新官网 hashes.txt更新官网 downloads.yml更新 auto-update DNS 记录钱包/节点自动更新机制依赖的 DNS 记录更新下载框的重定向规则downloads box redirects更新 seed nodes种子节点种子节点更新涉及 P2P 层的引导逻辑。从 src/p2p/net_node.inl 源码看MIN_WANTED_SEED_NODES为 12节点通过 DNS seedget_dns_seed_nodes与 IP seedget_ip_seed_nodes两种方式获取初始 peer 列表当 DNS seed 结果不足MIN_WANTED_SEED_NODES时会回退fallback到编译进二进制的 IP 种子节点列表m_fallback_seed_nodes_added标志控制只回退一次。因此新版本发布时新增的稳定节点既要反映到 DNS seed 记录也要视需要更新代码内的 IP 种子列表以保证新节点在引导阶段有足够的初始 peer。8.3 GUI 发布https://www.getmonero.org/downloads/ 更新下载页更新官网 hashes.txt更新官网 hashes.txt.sig哈希文件的签名保证完整性更新官网 downloads.yml更新 auto-update DNS 记录更新下载框的重定向规则GUI 与 CLI 的差异在于 GUI 额外需要发布hashes.txt.sig由发布者私钥对哈希文件签名供用户验签。九、最终发布公告Monero-announce 邮件列表通知Twitter 公告Reddit 公告Getmonero.org 公告至此一次完整的 Monero 硬分叉发布闭环完成从审计到硬件钱包、从分叉高度到生态通知、从代码变更到双网验证、从可复现构建到多渠道公告。检查清单中的每一项都对应一个可验证的交付物保证全网节点、钱包、交易所与矿池在分叉时刻到来前全部就位。十、清单的工程意义与使用建议回顾整份 docs/RELEASE_CHECKLIST.md它对同类区块链项目尤其是需要协调大量外部服务商的共识升级有很强的借鉴意义以共识为中心的任务分解把改代码之外的所有协调性工作显式化——硬件钱包、钱包、交易所、支付处理器、矿池、公告渠道全部纳入清单避免代码合了但生态没跟上的链分裂风险。可验证的发布制品版本号src/version.cpp.in、硬分叉参数src/hardforks/hardforks.cpp、硬编码检查点src/checkpoints/checkpoints.cpp、预计算块数据src/blocks/checkpoints.dat与校验常量src/cryptonote_core/blockchain.cpp五者环环相扣任何一个不一致都会被节点日志暴露。渐进式验证路径主网 → Testnet → Stagenet 的三段式验证加上可复现构建的哈希一致性校验把风险在进入主网前逐层过滤。在实际执行时建议将本清单作为 release PR 的描述模板逐项勾选并附上对应文件变更的 diff 链接涉及外部协作的项Ledger/Trezor 固件、钱包与交易所升级需预留充足的提前量因为它们的发布节奏不受 Monero 仓库控制。赞分享区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载相关推荐kotlinx.coroutines 版本发布全流程RELEASE.md 发布检查清单深度解析kotlinx.coroutines 版本发布全流程RELEASE.md 发布检查清单深度解析 kotlinx.coroutines 是 Kotlin 官方协异步编程并发编程OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程 导读 本文基于 OmniRoute 官方运维文档 docs/ops/REL后端API网关LLM 网关人工智能大模型MCP 服务桌面应用ijkplayer 版本发布全流程指南基于 preflight_checklist 的 Release/Takeoff 预检清单解析ijkplayer 版本发布全流程指南基于 preflight_checklist 的 Release/Takeoff 预检清单解析 导读 本文以 doc/p音视频移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Monero 硬分叉发布全流程解析：基于 RELEASE_CHECKLIST 的端到端版本发布检查清单实战指南
区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载导读Monero 采用定时软硬件升级硬分叉机制持续推进共识规则演进每一次网络升级都是一次跨代码、跨生态的高风险工程。本文以仓库内 docs/RELEASE_CHECKLIST.md 这份官方发布检查清单为骨架结合 硬分叉表、检查点机制、版本定义模板 等源码完整拆解从审计、硬件钱包集成、分叉高度设定、生态通知、Release 分支代码变更、Testnet/Stagenet 验证到最终发布公告的每一个环节。读完本文你将掌握一次 Monero 硬分叉版本从代码冻结到全网公告的全部步骤、涉及的仓库文件与命令行操作并理解检查点校验、可复现构建等核心环节的底层实现原理。一、发布清单在 Monero 发布流程中的定位Monero 的版本发布与网络升级是绑定进行的。根据 README.md 的说明Monero 使用定时软件/网络升级hard fork机制来引入新功能软件升级在代码库中开发并实现新功能网络升级则在修改共识规则的软件升级发布时同步发生且升级所需的软件会在计划升级日期之前提供。README 中以表格形式维护了每个升级的块高度 / 日期 / Fork 版本 / 最低 Monero 版本 / 推荐 Monero 版本 / 详情并注明在计划软件升级前大约三个月会从 master 创建带新版本号标签的分支修复 bug 的 PR 应同时提交到 master 与新的 release 分支需要大量评审与测试的改动一般是优化与新特性不应进入 release 分支。docs/RELEASE_CHECKLIST.md正是执行这条流程的操作手册它将整个发布过程组织为 9 个相互依赖的阶段代码与安全审计Ledger / Trezor 硬件钱包集成分叉高度设定与公告通知钱包、交易所、支付处理器、矿池Release 分支创建与代码变更版本号、README、检查点Testnet 分叉与验证Stagenet 分叉与验证CLI / GUI 可复现构建与发布最终发布公告清单采用 Markdown 复选框- [ ]形式每一项都可勾选天然适合作为 PR 或 issue 模板逐项跟进。二、第一阶段代码与安全审计发布的第一步不是写代码而是验证代码Security audit安全审计针对新引入的共识规则、密码学实现如新签名方案、环签名变体与 RPC 面进行独立安全审查。Monero 对共识代码的变更极其敏感任何可导致链分裂或资金风险的缺陷都必须在此阶段暴露。Code audit代码审计对代码质量、边界条件、资源管理与向后兼容性做系统性评审。结合 README.md 中需要大量评审与测试的改动不应进入 release 分支的原则审计重点是确认进入 release 分支的只有 bug 修复与共识必需的改动。审计结论将直接决定后续阶段是否启动是整条清单的门禁。三、硬件钱包集成Ledger 与 TrezorMonero 的用户大量依赖硬件钱包保管密钥每次共识规则变化分叉都会影响硬件钱包的签名与交易构造逻辑因此清单将硬件钱包集成单列为独立阶段。3.1 Ledger 集成检查项Ledger notified通知 Ledger 团队Pull request made against Monero codebase (if needed)如需要向 Monero 代码库提交 PRPull request merged into Monero codebase (if needed)如需要合入 PRLedger app integration codedLedger 应用集成编码Ledger Monero app update availableLedger Monero 应用更新上线仓库中 Ledger 支持的核心代码位于 src/device/其中 device_ledger.cpp 实现了通过 HID 与 Ledger 设备通信的完整逻辑device_io_hid.cpp 封装了底层 HID 传输层对应构建依赖见 cmake/FindHIDAPI.cmake。3.2 Trezor 集成检查项Trezor notifiedPull request made against Monero codebase (if needed)Pull request merged into Monero codebase (if needed)Trezor firmware update codedTrezor 固件更新编码Trezor firmware update availableTrezor 固件更新上线Trezor 支持位于 src/device_trezor/其中 device_trezor.cpp 与 device_trezor_base.cpp 实现设备交互src/device_trezor/trezor/ 目录内包含与 Trezor 固件通信的 protobuf 消息定义*.proto与序列化代码。构建期对 Trezor 的支持检测见 cmake/CheckTrezor.cmake。实践要点硬件钱包的 PR 必须在 Release 分支冻结前合入且固件/应用的更新要先于或同步于主软件发布否则分叉后硬件钱包用户将无法正常交易。四、设定分叉高度并对外公告分叉高度是共识变更的触发坐标。仓库中的硬分叉参数统一维护在 src/hardforks/hardforks.cpp其数据结构定义于 src/hardforks/hardforks.hstruct hardfork_t { uint8_t version; // 协议版本号 uint64_t height; // 触发分叉的区块高度 uint8_t threshold; // 升级投票阈值 time_t time; // 最终确定的激活时间戳 hardfork_t(uint8_t version, uint64_t height, uint8_t threshold, time_t time) : version(version), height(height), threshold(threshold), time(time) {} };例如主网历史分叉条目节选// version 6 starts from block 1400000, which is on or around the 16th of September, 2017. { 6, 1400000, 0, 1503046577 }, // version 15 / 16同一时间戳相邻高度触发两段升级 { 15, 2688888, 0, 1656629117 }, { 16, 2689608, 0, 1656629118 },清单要求分叉高度确定后通过三个渠道向社区公告Twitter announcementReddit announcementGetmonero.org announcement公告需明确分叉块高度与预计日期、用户需要升级到的最低版本并提醒服务商钱包、交易所、矿池提前升级节点。注意hardfork_t中的time字段是最终确定时间fork 不再有投票机制后threshold为 0实际触发以height为准这与 README fork 表Software upgrade block height列一一对应。五、生态通知钱包、交易所、支付处理器与矿池共识升级影响所有依赖节点与交易格式的服务方清单要求主动逐一通知而非等对方发现5.1 通知钱包13 家MyMoneroCoinomiExa WalletWookey WalletX WalletGuardaZelCoreCake WalletMonerujoEdge WalletExodusXMRWalletFeather Wallet5.2 通知交易所依据 https://www.getmonero.org/community/merchants/#exchanges 维护的交易所清单逐一联系5.3 通知第三方支付处理器依据 https://www.getmonero.org/community/merchants/#payment-gateways 维护的网关清单逐一联系BTCPayServer5.4 通知矿池依据 https://miningpoolstats.stream/monero 上活跃的 Monero 矿池清单逐一联系实践要点通知内容应包含分叉高度、激活时间、最低节点版本、新增/变更的共识规则摘要以及必要的迁移指引。交易所与支付处理器通常需要停机升级与回归测试越早通知升级窗口越充裕。六、Release 分支创建与代码变更核心工程环节这是清单中技术含量最高的一节共 5 项代码变更全部有对应的仓库文件支撑。所有变更都应在从 master 拉出的 release 分支上完成参考 README.md 的分支策略。6.1 更新版本号与版本名清单Update src/version.cpp.in with new version AND new name (if necessary)版本定义模板位于 src/version.cpp.inCMake 在构建时用实际配置替换...占位符后生成版本源码。当前仓库的版本信息如下#define DEF_MONERO_VERSION_TAG VERSIONTAG #define DEF_MONERO_VERSION 0.18.1.0 #define DEF_MONERO_RELEASE_NAME Fluorine Fermi #define DEF_MONERO_VERSION_FULL DEF_MONERO_VERSION - DEF_MONERO_VERSION_TAG #define DEF_MONERO_VERSION_IS_RELEASE VERSION_IS_RELEASE导出的全局变量被monerod、monero-wallet-cli等所有二进制共享MONERO_VERSION、MONERO_RELEASE_NAME、MONERO_VERSION_FULL、MONERO_VERSION_IS_RELEASE。发布时需将DEF_MONERO_VERSION改为新版本号如0.18.2.0若官方为本版本命名如 Fluorine Fermi 风格的化学元素代号同步更新DEF_MONERO_RELEASE_NAMEDEF_MONERO_VERSION_IS_RELEASE在正式发布构建中由 CMake 置为1开发构建为0。6.2 更新 README 的 fork 表清单Update README.md with new fork table entry (or at least update the Recommended Monero version)README.md 中的软件升级表以块高度 / 日期 / Fork 版本 / 最低版本 / 推荐版本 / 详情六列维护每个升级发布时需为本次分叉新增一行并更新该表的Recommended Monero version为本次发布版本让生态开发者一眼看清需要升级到什么版本。6.3 更新硬编码检查点清单Update src/checkpoints/checkpoints.cpp with a recent hardcoded checkpoint硬编码检查点用于快速同步与防回滚保护位于 src/checkpoints/checkpoints.cpp 的load_hardcoded_checkpoints主网部分以宏形式追加最新高度条目例如ADD_CHECKPOINT2(2720000, b19fb41dff15bd1016afbee9f8469f05aab715c9e5d1b974466a11fd58ecbb86, 0x3216b5851ddbb61);宏的三个参数分别是区块高度、区块哈希、累计难度十六进制。对应的方法签名定义在 src/checkpoints/checkpoints.hbool checkpoints::add_checkpoint(uint64_t height, const std::string hash_str, const std::string difficulty_str);硬编码检查点只增不删发布时追加当前链头附近的最新检查点即可。6.4 重新生成 checkpoints.dat清单Update src/blocks/checkpoints.dat with ./monero-blockchain-export --output-file checkpoints.dat --block-stop recent block height --blocksdat这是清单中唯一一条命令行操作用于从同步好的本地链导出预计算块哈希数据命令原型为./monero-blockchain-export --output-file checkpoints.dat --block-stop recent block height --blocksdat其中--output-file checkpoints.dat导出文件名--block-stop recent block height导出到哪个高度为止一般取接近链头的高度--blocksdat以 blocks.dat 格式输出。对应参数在 src/blockchain_utilities/blockchain_export.cpp 中定义const command_line::arg_descriptoruint64_t arg_block_stop {block-stop, Stop at block number, block_stop}; const command_line::arg_descriptorbool arg_blocks_dat {blocksdat, Output in blocks.dat format, blocks_dat};导出逻辑通过BlocksdatFile::store_blockchain_raw(...)完成见 src/blockchain_utilities/blocksdat_file.cpp导出结果直接落盘为 src/blocks/checkpoints.dat。6.5 更新预计算块哈希的校验值清单Update expected_block_hashes_hash in src/cryptonote_core/blockchain.cpp with checkpoints.dat sha256 hash节点在快速同步fast sync模式下会加载编译进二进制的checkpoints.dat并对其做完整性校验。校验常量与逻辑位于 src/cryptonote_core/blockchain.cpp受PER_BLOCK_CHECKPOINT编译宏保护#if defined(PER_BLOCK_CHECKPOINT) static const char expected_block_hashes_hash[] 2aea941d43024422a63f223c84b9d88d1f58d31e1f508c2d6d43cd637ba32d16; void Blockchain::load_compiled_in_block_hashes(const GetCheckpointsCallback get_checkpoints) { if (get_checkpoints nullptr || !m_fast_sync) { return; } ... if (m_nettype MAINNET) { // first check hash crypto::hash hash; if (!tools::sha256sum(checkpoints.data(), checkpoints.size(), hash)) { MERROR(Failed to hash precomputed blocks data); return; } MINFO(precomputed blocks hash: hash , expected expected_block_hashes_hash); ... if (hash ! expected_hash) { MERROR(Block hash data does not match expected hash); return; } }底层格式从load_compiled_in_block_hashes的解析代码可以还原checkpoints.dat前 4 字节为小端uint32_t块数nblocks随后是nblocks × (sizeof(crypto::hash) × 2)字节的数据每块两个 32 字节哈希。节点校验逻辑如下const uint32_t nblocks *p | ((*(p1))8) | ((*(p2))16) | ((*(p3))24); if (nblocks (std::numeric_limitsuint32_t::max() - 4) / sizeof(hash)) { ... return; } const size_t size_needed 4 nblocks * (sizeof(crypto::hash) * 2); if (checkpoints.size() ! size_needed) { ... }因此发布流程是先执行 6.4 的导出命令 → 计算新checkpoints.dat的 SHA-256 → 用该值替换expected_block_hashes_hash字符串。两者必须同步更新否则主网节点会打印Block hash data does not match expected hash并拒绝加载预计算块。提示检查点文件缺失时节点仍可正常启动load_checkpoints_from_json在文件不存在时返回true并提示 Blockchain checkpoints file not found但快速同步能力会退化因此不要遗漏该步骤。七、Testnet 与 Stagenet 分叉与验证正式发布前新共识规则必须在测试网与暂存网完整走一遍。7.1 Testnet 分叉与验证Testnet forkedTestnet testing/verificationLedgerTrezorRelease-specific testing针对本次发布特性的专项测试RPC testing / update RPC documentationRPC 测试并更新 RPC 文档7.2 Stagenet 分叉与验证Stagenet forkedStagenet testing/verificationLedgerTrezorRelease-specific testing测试网与暂存网的分叉参数分别维护在 src/hardforks/hardforks.cpp 的testnet_hard_forks[]与stagenet_hard_forks[]数组中hardfork_t结构与主网一致并在 src/hardforks/hardforks.h 中声明导出。三个网络的检查点 JSON 与 DNS 源也各自独立见 src/checkpoints/checkpoints.cpp 中checkpoints.moneropulse.*、testpoints.moneropulse.*、stagenetpoints.moneropulse.*三组 DNS 域。验证重点硬件钱包Ledger / Trezor在测试网完成全流程交易签名针对本次升级特性的专项测试如新的交易格式、新的环签名、新的费用算法RPC 接口行为变化要同步更新 RPC 文档相关命令定义见 src/rpc/core_rpc_server_commands_defs.h 与 src/wallet/wallet_rpc_server_commands_defs.h。八、可复现构建验证与 CLI / GUI 发布8.1 CLI 可复现构建验证CLI reproducible builds validatedMonero 通过 contrib/guix/ 提供基于 GNU Guix 的可复现构建环境核心描述文件为 contrib/guix/manifest.scm配套guix-attest、guix-verify、guix-clean等脚本配合 contrib/depends/ 的依赖锁定机制确保任何人在任何机器上构建出的二进制哈希一致。这一步为后续在官网公布hashes.txt提供可信依据。8.2 CLI 发布https://www.getmonero.org/downloads/ 更新下载页更新官网 hashes.txt更新官网 downloads.yml更新 auto-update DNS 记录钱包/节点自动更新机制依赖的 DNS 记录更新下载框的重定向规则downloads box redirects更新 seed nodes种子节点种子节点更新涉及 P2P 层的引导逻辑。从 src/p2p/net_node.inl 源码看MIN_WANTED_SEED_NODES为 12节点通过 DNS seedget_dns_seed_nodes与 IP seedget_ip_seed_nodes两种方式获取初始 peer 列表当 DNS seed 结果不足MIN_WANTED_SEED_NODES时会回退fallback到编译进二进制的 IP 种子节点列表m_fallback_seed_nodes_added标志控制只回退一次。因此新版本发布时新增的稳定节点既要反映到 DNS seed 记录也要视需要更新代码内的 IP 种子列表以保证新节点在引导阶段有足够的初始 peer。8.3 GUI 发布https://www.getmonero.org/downloads/ 更新下载页更新官网 hashes.txt更新官网 hashes.txt.sig哈希文件的签名保证完整性更新官网 downloads.yml更新 auto-update DNS 记录更新下载框的重定向规则GUI 与 CLI 的差异在于 GUI 额外需要发布hashes.txt.sig由发布者私钥对哈希文件签名供用户验签。九、最终发布公告Monero-announce 邮件列表通知Twitter 公告Reddit 公告Getmonero.org 公告至此一次完整的 Monero 硬分叉发布闭环完成从审计到硬件钱包、从分叉高度到生态通知、从代码变更到双网验证、从可复现构建到多渠道公告。检查清单中的每一项都对应一个可验证的交付物保证全网节点、钱包、交易所与矿池在分叉时刻到来前全部就位。十、清单的工程意义与使用建议回顾整份 docs/RELEASE_CHECKLIST.md它对同类区块链项目尤其是需要协调大量外部服务商的共识升级有很强的借鉴意义以共识为中心的任务分解把改代码之外的所有协调性工作显式化——硬件钱包、钱包、交易所、支付处理器、矿池、公告渠道全部纳入清单避免代码合了但生态没跟上的链分裂风险。可验证的发布制品版本号src/version.cpp.in、硬分叉参数src/hardforks/hardforks.cpp、硬编码检查点src/checkpoints/checkpoints.cpp、预计算块数据src/blocks/checkpoints.dat与校验常量src/cryptonote_core/blockchain.cpp五者环环相扣任何一个不一致都会被节点日志暴露。渐进式验证路径主网 → Testnet → Stagenet 的三段式验证加上可复现构建的哈希一致性校验把风险在进入主网前逐层过滤。在实际执行时建议将本清单作为 release PR 的描述模板逐项勾选并附上对应文件变更的 diff 链接涉及外部协作的项Ledger/Trezor 固件、钱包与交易所升级需预留充足的提前量因为它们的发布节奏不受 Monero 仓库控制。赞分享区块链金融科技【免费下载链接】moneroMonero: the secure, private, untraceable cryptocurrency项目地址https://gitcode.com/gh_mirrors/mo/monero点击查看免费下载相关推荐kotlinx.coroutines 版本发布全流程RELEASE.md 发布检查清单深度解析kotlinx.coroutines 版本发布全流程RELEASE.md 发布检查清单深度解析 kotlinx.coroutines 是 Kotlin 官方协异步编程并发编程OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程 导读 本文基于 OmniRoute 官方运维文档 docs/ops/REL后端API网关LLM 网关人工智能大模型MCP 服务桌面应用ijkplayer 版本发布全流程指南基于 preflight_checklist 的 Release/Takeoff 预检清单解析ijkplayer 版本发布全流程指南基于 preflight_checklist 的 Release/Takeoff 预检清单解析 导读 本文以 doc/p音视频移动开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考