Drupal12的发布周已写进官方日程，站点排期要不要提前腾窗口
需要。开源项目的发布日程是可预期的，Drupal 官方核心发布节奏页已经写明下一大版本排在 2026 年 12 月那一周，同页还列出部分分支结束安全支持的节点。既定的日程意味着升级窗口可以提前排进年度维护表，而不是等通告当天临时处理。
官方日程能告诉站点什么
发布节奏页给的是两类信息：主版本的时间点，与各分支安全支持的截止线。前者用来安排预发布与人力，后者用来判断哪些站点必须在这个周期内完成跟进。它不告诉你兼容成本有多大，也不替你决定要不要跟进，但足以把“被动应对”改成“排期处理”。
反过来，把日程当成不需要行动的依据也常见。时间点是发布，不是你的站点完成迁移，中间还差回归测试与数据检查两段工作。
三种排期分别怎么腾窗口
| 类型 | 触发方式 | 建议预留时长 | 主要动作 |
|---|---|---|---|
| 大版本升级 | 官方日程公布 | 按页面种类与自定义代码量估，先做可行性验证 | 预发布环境全量回归，模板与字段核对 |
| 次版本更新 | 随功能新增发布 | 一个工作日加一轮回归 | 关注新增默认行为是否影响现有内容 |
| 安全修复 | 按通告节奏，常提前公告时间窗 | 通告窗口内完成 | 备份、升级、验证、留档 |
大版本是项目级排期，安全修复是值班级动作，两者混在同一张表里容易漏掉后者。安全通告通常会写明发布时间窗口，站点要按那个窗口预留维护时段，而不是假设可以在业务低峰临时插入。
腾窗口前的三件事
- 可回滚的备份。范围要包含数据库与静态文件，只备库的恢复演练在图片丢失时就暴露问题；备份完成后做一次真实恢复，别只确认文件存在。
- 独立预发布环境。用于验证模板、字段与接口调用，与生产同版本同配置才有意义。用 Docker 镜像部署的站点起一份副本较快，走面板一键部署的要确认能复制环境。
- 内容冻结时段。升级期间新增内容容易落在两套结构之间，把发布动作切到待发布状态，等验证通过再统一上线，比事后修补成本低。
第三点常被忽略。站点在升级当天仍有人发新文章，回滚时就要决定这些内容是保留还是重做，提前冻结比临场判断更省事。
升级当天与之后
顺序按四步走：先确认备份可用；再升级运行环境与程序本体；然后逐项验证列表页、详情页、表单提交与后台登录；最后把版本号、耗时、遇到的问题记进站点台账。
凭证处理要放在同一天完成。以 v3.6.6 为例，这一版修复了列表排序参数的 SQL 注入与站点切换时登录凭证可被伪造两处高危问题，升级建议同时要求轮换站点签名密钥并修改管理员口令；只升程序不动凭证，等于把可被伪造的那条路径留着。类似地，一次性票据机制变更后，旧会话是否仍然有效要确认清楚。
把版本跟进写进年度维护表
三行就够：日程行（已知的主版本发布周与安全支持截止线）、责任人行（谁腾窗口、谁做验证）、检查行（每季度确认一次备份可恢复、预发布环境仍在）。维护表的价值在于安全通告来临时能立刻知道该动哪个站点，而不是临时找负责人。
常见问题
问：站点规模小，能不能等大版本稳定后再跟？ 答：可以，但要区分大版本与安全修复。推迟大版本是策略，推迟安全修复是风险敞口，二者不要写进同一条决定。
问：预发布环境一定要和生产同配置吗？ 答：尽量同版本同配置，否则验证结论不可靠。至少保证运行时版本、数据库类型与程序版本一致。
问：升级失败最坏情况怎么处理？ 答：回到升级前的备份点。这就是为什么备份要在升级前做、并且要在窗口前验证过可恢复，临时备份往往来不及验证。