结论先行：WordPress 核心团队宣布，从 WordPress 7.2（计划 2026 年 12 月初发布）开始，版本发布不再绑定线下活动现场，改为线上直播形式（Zoom 网络研讨会）。此前两轮线下尝试——2025 年的 State of the Word 和刚刚的 WordCamp US 上的 7.1——被官方定性为「一次不错的实验」，但物流、人力与参与名额上的代价过高，发布小组的反馈也确认了这一点。
线下发布到底卡在哪里
把发布搬到舞台上，初衷是让 WordPress 的重要时刻有更强的仪式感和传播度。执行下来，核心团队列出了三个绕不过去的约束：
- 物流复杂。发布节奏要迁就活动日程，而不是迁就代码状态。
- 人力被摊薄。在活动现场同时管理发布流程和活动事务，两边都吃力。
- 名额天然有限。能到现场的发布小组成员终究是少数，多数人只能旁观。
更关键的一句是发布小组的直接反馈：把一套本来就不是为「在舞台上执行」设计的流程搬上台，会带来真实的压力。发布是有序的高风险操作，需要的是安静、可回滚、随时能暂停的环境，这与现场直播的不可逆性天然冲突。
直播方案具体怎么做
官方给出的形态是一次网络研讨会式的 Zoom 直播：
- 发布小组成员和深度参与本次发布的人在会上分享；
- 其他人可以观看并提问；
- 不再绑定固定的活动日期，时间由发布本身决定；
- 目标是让更多发布小组成员真正参与进来（时区允许的前提下），且不产生参会的经济负担。
换句话说，改的不只是「线上还是线下」，而是主导权：从「活动日程决定发布怎么走」变成「发布需要什么就安排什么」。参与方式等细节会在临近发布时公布。
两种发布形式对比
| 维度 | 线下活动现场 | 线上直播（7.2 起） |
|---|---|---|
| 时间主导权 | 受活动日程约束 | 由发布进度决定 |
| 参与门槛 | 需到场，名额与费用受限 | 链接即可参与，时区是主要限制 |
| 可参与人数 | 现场座位决定 | 理论上覆盖整个发布小组 |
| 执行压力 | 流程为舞台改造，压力高 | 回到熟悉的执行环境 |
| 传播效果 | 现场氛围强，媒体曝光高 | 可回放，长尾可达性更好 |
| 风险处置 | 直播不可逆，容错低 | 可暂停、可延后，容错更高 |
对普通站长意味着什么
表面上看，这是核心团队内部的工作方式调整，跟日常运维没关系。但往下想一层，影响是实的：
- 发布节奏会更稳定。不再等某个大会的档期，版本能按自身成熟度上线，安全补丁尤其受益。
- 发布过程更透明。线上直播可回放，你能在事后看到某个决策是怎么做的，而不是只读到一篇总结。
- 参与门槛降低，贡献路径更宽。配合已经落地的 贡献者工具箱 1.2，「围观一次真实发布」这件事第一次变得几乎零成本。
- 7.2 的时间点值得记一下。官方口径是 2026 年 12 月初，如果你的站点有大版本升级计划，提前留出兼容性测试窗口。
怎么围观一次真实的 WordPress 发布
- 直播链接、议程与提问方式会在临近发布时公布，关注 make.wordpress.org/core 上的 release-process 标签即可。
- 直播按发布进度安排，跨时区参与是常态。把时间换算成本地时间并留出缓冲，避免只在事后看回放。
- 带着上下文看发布，能听懂「这个功能为什么这次没进」的讨论。可参考我们整理的 WordPress 7.2 路线图。
- 研讨会形式允许提问。与其问「什么时候发布」，不如问某个改动对你所在场景的影响，这类问题更容易得到有价值的回答。
- 发布直播最有信息量的部分往往不是「做了什么」，而是「什么被拿掉了、为什么」。这决定了你下一轮升级会遇到什么。
常见问题
为什么不在 WordCamp 上发布了？
线下发布试了两轮，暴露出物流复杂、人力紧张、到场名额有限三个问题。发布小组反馈也指出，把非为舞台设计的流程搬上台会增加额外压力。直播形式保留仪式感的同时解除了这些约束。
线上直播会不会让发布变得没有仪式感？
形式变了，仪式感可以靠别的方式补——统一的开场、核心贡献者轮流发言、实录回放，都是可沉淀的内容。相比现场两小时的曝光，可回放的直播长尾触达其实更好。
普通用户可以提问吗？
可以。官方描述的形态就是研讨会：发布小组成员与深度参与者分享，其他人观看并提问。具体提问入口会随参与方式一起公布。
这个改变会影响 7.2 的发布时间吗？
官方口径仍是 2026 年 12 月初。理论上解绑活动日程后，发布时间更可能由代码成熟度决定，反而更稳定。
补充说明
文中用到的排版容器都是主题原生短代码：提示框写作 [jinyu_tip type=”info”]…[/jinyu_tip]，折叠块是 [jinyu_collapse title=”标题”]…[/jinyu_collapse]，分步教程用 [jinyu_howto] 包 [jinyu_step]，问答用 [jinyu_faq] 包 [jinyu_faq_item q=”问题”]，按钮是 [jinyu_btn url=”链接” text=”文字”]。讲解这些语法时方括号要写成实体编码，否则会被主题直接解析。想理解发布流程背后那套工具链，可以接着读 核心发布工具开源 那一篇。
评论 (0)