发布节奏解决「什么时候发」，回滚 runbook 解决「发错了怎么办」。后者必须在前者之前存在。
一、三个地方写着三个版本号
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
闻笛发布 2.4.0 后，一半用户仍停留在 2.3.2。
排查发现三处不一致：安装包内的版本是 2.4.0，更新清单里写的是 2.4.0，但商店后台的构建号还是上一次的。更新器比较后认为「已是最新」，于是不再提示。
更糟的是，两天后他决定撤回：官网只保留了最新安装包，旧版本没有归档，用户想退回也没有文件。
版本一致性不是格式问题，是交付正确性问题。 三处任何一处落后，用户就会卡在中间状态。
二、发布列车：固定窗口与紧急通道
固定节奏能减少决策疲劳，也能让用户形成预期。
常规列车
每两周一个窗口，固定星期与时间
冻结期：发布前 24 小时只修阻断问题
窗口内只发一个版本，不叠加新功能
紧急通道
触发条件：崩溃、数据损坏、安全问题
最小改动，只包含修复
发布后 24 小时内补一份复盘
固定窗口的好处是可预测。 用户、客服与内容更新都能按节奏安排；临时发布会让所有下游动作重新排一次。
窗口长度要匹配产能。 一个人的产品，两周一次通常比每周一次更稳；频率过高会让冻结期占掉大部分时间。
冻结期必须真的冻结。 发布前 24 小时合入新功能，等于把未验证的改动带进发布；只允许阻断性修复。
紧急通道要写清触发条件。 「很急」不是条件；崩溃率、数据损坏、安全漏洞才是。条件不清，紧急通道会被日常需求占用。
紧急版本只修一个问题。 一次塞进多个修复，出问题后无法判断是哪一处；最小改动也让回滚更简单。
发布记录要包含版本、构建号、变更与已知问题。 它是回滚与客服的共同依据，不只是给用户看的公告。
三、三处版本一致性
每次发布前，逐项核对三个位置。
| 位置 | 检查内容 | 常见偏差 |
|---|---|---|
| 安装包 | 版本号、构建号、架构 | 构建号未递增 |
| 更新清单 | 最新版本、下载地址、校验和 | 清单缓存未刷新 |
| 商店后台 | 版本号、构建号、分阶段比例 | 构建号与安装包不一致 |
构建号必须单调递增。 版本号可以重复用于不同分支，构建号不行；商店与更新器通常以构建号判断新旧。
构建号要由 CI 生成。 手工填写迟早会重复；用递增序号或时间戳，并写进发布记录。
更新清单要避免长时间缓存。 清单被 CDN 缓存数小时，用户会在一段时间内看不到新版本；发布后主动刷新并验证。
商店后台的构建号要与安装包一致。 上传错包、选错构建，是「发布成功但用户没更新」的常见原因。
三处一致后再发公告。 公告发出但用户下载不到，会产生大量「为什么我还是旧版」的工单。
四、兼容窗口与回滚 runbook
版本不是孤立的，新旧版本会同时存在一段时间。
N−2 兼容窗口。 服务端至少兼容最近三个客户端版本；低于窗口的版本给出升级提示，而不是直接报错。
兼容窗口要写进接口文档。 哪些字段会保留、哪些会下线、提前多久通知，用户与合作方都需要一个明确口径。
只向前迁移数据。 新版写出的数据格式，旧版可能读不了；升级前备份，降级时提供只读模式或迁移工具。
服务端 API 要版本化。 客户端更新不可控，接口变更必须保留旧版本一段时间；下线前先观察调用量。
回滚是产品能力，不是应急表演。 下面这份 runbook 应该在一页纸上，任何人拿到都能执行。
回滚 runbook
1. 判断范围：仅新版本、特定渠道，还是服务端配置
2. 停止扩大：暂停灰度、下架安装包、关闭更新清单
3. 恢复旧版：重新上架归档的旧安装包，校验和与签名不变
4. 数据边界：确认旧版能读当前数据；不能读则进入只读
5. 通知：公告写清影响范围、临时方案与下次更新时间
6. 复盘：记录触发信号、决策时间与恢复时间
旧安装包必须长期归档。 至少保留最近三个版本，包含安装包、校验和与签名信息；只留最新版，回滚时无包可用。
归档要包含签名材料。 只留安装包，重签时仍可能失败；证书、公证票据与校验和一起归档，才能在紧急时直接上架。
服务端配置优先于客户端回滚。 能通过开关关闭的功能，先关开关；客户端回滚最慢，也最容易产生数据问题。
数据回滚要谨慎。 已经写入的新格式数据，强行降级可能损坏；优先只读、导出与向前修复。
五、行动清单与复算验收
- 固定常规发布窗口、冻结期与紧急通道触发条件
- 每次发布核对安装包、更新清单、商店后台的版本与构建号
- 确认构建号单调递增，并写入发布记录
- 定义 N−2 兼容窗口与低版本提示策略
- 归档最近三个版本的安装包、校验和与签名
- 写一页回滚 runbook，并实际演练一次
- 准备服务端开关，优先用配置回滚
- 回滚后 24 小时内完成复盘并更新记录
验收标准：能在三十分钟内按 runbook 让用户重新下载到上一个可用版本。 没演练过的 runbook，只能算草稿。
回滚 MTTR = 旧版可下载时间 − 决定回滚时间
示例：决定 10:00，旧版重新可下载 10:26 → MTTR 26 分钟
已升级比例 = 灰度窗口内升级用户 ÷ 活跃用户
紧急通道占比 = 紧急版本数 ÷ 总发布数
高于 30% 说明常规列车没有吸收必要修复
使用边界与实操验收
本文只讲版本节奏与回滚决策，不涉及安装包格式与更新器实现（第 04 篇）、移动端灰度档位（第 07 篇）与商店审核材料（第 08 篇）。
浏览器扩展的版本回滚属于Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘 ；发布产物的归档与找回属于代码与仓库：多远程、组织所有权、镜像与归档 ；更新日志作为获客内容属于自有渠道：邮件列表、更新日志与推荐 。
本文也不主张「每个版本都必须保留三个旧包」。存储成本可忽略，但归档要可检索；关键是回滚时能在几分钟内找到对应版本，而不是翻聊天记录。
验证以恢复时间为准：每季度演练一次回滚，记录从决定到旧版可下载的分钟数。超过一小时，说明归档、权限或流程至少有一处断了。
关键参考与核验范围
本文的节奏与阈值为教学演示，实际策略请结合产品规模调整。核验日期：2026-10-24。
- Semantic Versioning 2.0.0 ：语义化版本号的定义与构建号用法。
- Keep a Changelog ：变更日志的结构约定，可作为发布记录模板。
上述两条只用于说明公开规范，不构成对版本策略的建议。客户端与商店的版本比较规则可能不同，实施前请核对平台文档。
系列导航
- 上一篇：原生商店审核：Mac App Store、Microsoft Store 与 App Store 的拒绝点
- 下一篇：商店页素材：截图顺序、演示视频与版本同步验收
- 回到目录：一个人把软件交付到用户手里：签名、安装、更新与审核
- 相关阅读：代码与仓库：多远程、组织所有权、镜像与归档 、自有渠道：邮件列表、更新日志与推荐
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。