That week, the old branch was stopped just as the new version was released, what should the site running Drupal do first?
The week of Drupal 12 release, Drupal 10 is exactly at the point of discontinuation of support, what should the Drupal site do first? First, do the backup acceptance, then discuss the upgrade scheduling. The official scheduling page writes the large version release window and the end of support next to each other, the site cannot rely on 'wait and see', nor should it directly move the main line without a recoverable backup.
Why would two time points collide in a week
Drupal's release rhythm is to provide a fixed support cycle for the main line first, and then let the next major version take over at the end of the cycle. According to the visible schedule on the day, Drupal 12 is scheduled to be released in the first week of December, and the end of support for Drupal 10 falls two days later in the same week. The collision is not an accident, but the result of scheduling design: the project binds 'new version available' and 'old version no longer secure' at the same time point, forcing the ecosystem to move forward.
The impact on the site is that you cannot stop at the old branch and wait, nor can you start the first migration evaluation on the day of the shutdown.
| Timing point | Actions to be completed by the site | Common misjudgment |
|---|---|---|
| Three months before the shutdown | Count module and theme compatibility | Only check if there is a new version of the module |
| One month before the shutdown | Complete one recoverable backup exercise | Thinking that the backup file exists is the same as being able to recover |
| The week of the shutdown | Freeze unnecessary changes | Modify content and upgrade simultaneously in the same window |
| After stopping updates | Migrate or move to controlled status | Continue to provide write access externally |
Check which backup to verify before upgrading
The backup is only considered verified if it has been restored once. Just exporting, without performing a restore, is the same as not doing a backup. The verification at least covers three things: whether the data itself can be imported into a clean environment, whether all attachments and static files are complete, and whether the site can log in and publish after restoration.
AnQiCMS in this scenario takes the approach of including data and static files in the backup and recovery capabilities, and the recovery drills can be done on independent instances. The self-built system in the v3.6.6 announcement simultaneously fixed two issues: list sorting parameter injection and the login credentials of site switching being forgeable. The suggested treatment is also the same sequence: backup first, then upgrade, and after the upgrade, rotate the signature configuration and change the administrator password. This sequence is also applicable to the preparation before migration when scheduling conflicts occur.
How to arrange the order of module compatibility
First, look at the writeable modules: forms, payment, import and export, comments, and member-related modules, which directly touch data and permissions; secondly, look at the modules that rewrite page output, such as cache, templates, and search engine-related modules; lastly, pure display modules.
When scheduling is tight, split the windows according to these three levels: postpone what can be postponed first, complete the writeable and authentication sides that must be done before the update is stopped, and pure display modules can be moved after the new main line is stable.
What are the choices after the old branch is stopped?
Three paths: migrate to the new main line; stay on the old branch but narrow the exposed surface, close the public write entry, and only retain static output; or rely on third-party support schemes that continue to provide patches for old versions. The second option is passive and only suitable as a transitional state, not suitable for long-term operation.
Common questions
Does the end of support mean stopping security patches as well?The end of major version support means that the official will no longer provide any patches, including security patches, which is a concept different from 'only stop feature updates'.
Will it be more stable to upgrade early?It is usually safer to migrate to a newer version still in the support cycle before the end of support, but it needs to be verified in a non-production environment first.
Is the release date always on time?The schedule is the official plan, but it may be delayed in practice. Sites should prepare according to the plan rather than bet on the plan.