大版本发布周和旧分支停止支持落在同一旬，站点先做哪一步
大版本发布周和旧分支停止支持落在同一旬，站点先做哪一步？先做当期安全补丁，再做备份与回滚演练，最后才排大版本迁移。当天核对到的排期能说明节奏：Drupal 12 定在十二月七日那一周发布，而 Drupal 10 的停止支持日期是十二月九日，两者相隔数日；核心安全发布通常落在每月第三个周三。
同一旬里挤了三件事
第一件是补丁供给要断。分支进入停止支持后不再出新安全修复，风险不是立刻发生，而是此后每个新漏洞都没有对应版本可打。
第二件是新大盘上线。大版本改的是模板机制、扩展接口与默认主题，跟过去等于把兼容性问题一次性揽到自己身上。
第三件是常规安全窗口照常来。按月节奏发布的安全补丁不会因为大盘临近就推迟，这一旬里要同时接住三件事，顺序错了就会手忙脚乱。
先打当期补丁再谈大版本
留在当前分支时，当期补丁是成本最低的动作：改动面小、回滚容易、模板不用重写。先把站点打到当前分支的末端版本，把安全性问题清零，再讨论要不要跨大版本。
跨大版本属于另一件事。要评估的是模板与扩展是否已适配、数据库结构变更能否回退、自定义接口是否还在。没有做完这些检查就升级，出现白屏或功能缺失时很难定位是哪一层造成的。
备份与回滚演练放在升级前
升级前的备份不是打个包就完事。数据与静态文件都要包含在内，并且要真的在另一台机器或另一份环境上恢复一次，确认恢复出来的站点能正常打开、后台能登录。没演练过的备份等于没有备份。
演练时顺带确认两件事：恢复要多久，这段时间站点是否可接受离线；以及是否留得出回滚窗口，升级失败能退回原版本而不是临时找包。
把内容系统的升级也排进同一张表
同一旬里不只有开源程序的日程，自托管内容系统自身也有版本动作。AnQiCMS（安企CMS）以 Docker 镜像部署或以宝塔面板一键部署时，镜像标签与主机上的版本要一起登记，避免主机已经换过而记录还停在旧版。
把三条线并进一张表：当月安全补丁日期、旧分支停止支持日期、自身系统的升级日期。表上任何一格到期前都要先做完备份，再执行。这张表的用途是让”谁在什么时间动什么”清楚，而不是留给值班的人临时判断。
常见问题
能不能跳过当期补丁直接升大版本？ 不建议。大版本迁移本身就会引入变量，再叠上未修的已知漏洞，出问题更难判断来源。
停止支持后还能继续用吗？ 短期能用，但没有补丁供给，风险随新漏洞累积，应尽快规划迁移路径。
升级窗口放在什么时候合适？ 放在业务低峰，并且预留一半时间用于回滚，不要把演练排在上线之后。