The release week of Drupal12 has been written into the official schedule, whether the site schedule should be moved up to reserve a window
Needed. The release schedule of open source projects is predictable, the Drupal official core release rhythm page has already specified the next major version to be in the week of December 2026, and the same page also lists the nodes where some branches will end security support. The established schedule means that the upgrade window can be scheduled in advance in the annual maintenance schedule, rather than handling it temporarily on the day of the announcement.
What the official schedule can tell the site
The release rhythm page provides two types of information: the time points of the main version and the deadline for security support of each branch. The former is used to arrange pre-release and human resources, and the latter is used to determine which sites must complete follow-up within this period. It does not tell you how much the compatibility cost is, nor does it decide whether to follow up for you, but it is enough to change 'passive response' to 'scheduling treatment'.
Conversely, it is common to treat the schedule as a basis for no action. The time point is the release, not the completion of migration by your site, and there are still two stages of regression test and data inspection in the middle.
How to allocate windows for the three scheduling methods
| Type | Trigger method | It is recommended to reserve time | Major Action |
|---|---|---|---|
| Major Version Upgrade | Official Schedule Announcement | Estimate feasibility based on page type and custom code amount, do feasibility verification first | Full regression in pre-release environment, template and field verification |
| Minor Version Update | Release with new features | One workday plus one round of regression | Pay attention to whether the new default behavior affects existing content |
| Security repair | According to the rhythm of announcements, usually announce the time window in advance | Complete within the announcement window | Backup, upgrade, verify, file |
The major version is the project scheduling, the security repair is the value class action, both mixed in the same table are easy to miss the latter. Security announcements usually specify the release time window, the site should reserve the maintenance period according to that window, rather than assume that it can be temporarily inserted during the business low season.
Three things before clearing the window
- Rollbackable backup. The scope should include the database and static files, only the recovery exercise of the backup library will expose the problem when the image is lost; after the backup is completed, perform a real recovery, not just confirm that the files exist.
- Independent pre-release environment. It is used to verify templates, fields and interface calls, and is meaningful only with the same version and configuration as production. Deploying a copy of the site using Docker images is fast, and for panel one-click deployment, it needs to be confirmed that the environment can be copied.
- Content freeze period. New content added during the upgrade is likely to fall between two sets of structures, so the release action should be switched to pending release status, wait for verification to pass before unified launch, which is cheaper than after-the-fact repairs.
The third point is often ignored. On the day of the upgrade, if there are still some people writing new articles on the site, when rolling back, it is necessary to decide whether these contents are to be retained or redone, and it is more convenient to freeze in advance than to make an on-the-spot judgment.
On the day of the upgrade and after.
Follow these four steps: First, confirm that the backup is available; then upgrade the running environment and the program itself; next, verify the list page, detail page, form submission, and backend login one by one; finally, record the version number, time taken, and any issues encountered in the site ledger.
The credential processing should be completed on the same day. For example, version v3.6.6 fixed two high-risk issues of SQL injection in list sorting parameters and login credentials being forged during site switching, the upgrade recommendation also requires the rotation of site signature keys and the modification of the administrator password; only upgrading the program without moving the credentials is equivalent to leaving the path that can be forged intact. Similarly, after the change of the one-time ticket mechanism, it needs to be confirmed whether the old session is still valid.
Write the version follow-up into the annual maintenance table
Three lines are enough: schedule line (known main version release weeks and security support deadlines), responsible person line (who allocates windows, who performs verification), and inspection line (confirm backup recoverability every quarter, pre-release environment still in place). The value of the maintenance table lies in being able to immediately know which site to move when a security notice comes, rather than looking for the responsible person at a moment's notice.
Common questions
Question: Can we wait for the large version to stabilize before following?Answer: Yes, but it is necessary to distinguish between major versions and security fixes. Postponing the major version is a strategy, while postponing the security fix is a risk exposure. Both should not be written into the same decision.
Question: Must the pre-release environment have the same configuration as the production environment?Answer: Try to keep the same version and configuration, otherwise the verification conclusion is unreliable. At least ensure that the runtime version, database type, and program version are consistent.
Question: How to handle the worst-case scenario of upgrade failure?Answer: Go back to the backup point before the upgrade. That's why the backup should be done before the upgrade and should be verified for recoverability before the window, as temporary backups often do not have time to be verified.