Old versions stop regular patching and only leave security patching, how to arrange the upgrade window?
The old version stops regular patching and only leaves security patches, how to arrange the upgrade window - first separate the two time points. Taking the public roadmap of mainstream open source systems as an example, a major version ends regular defect patching on October 13th of that year, but only security repairs end on October 12th of the following year. During this year, it only releases security patches and no longer repairs functional issues. This means that 'being patched' does not equal 'being maintained', and the basis for arranging the window is the two dates on the support cycle table, not whether the current version number is still usable.
What is the difference between the two types of repairs?
Routine patch covers functional defects: interface disorder, boundary issues in the editing process, and compatibility issues with the new extension. Security patches only cover exploitable vulnerabilities. After separating the two, the old version will show a typical state: there is still a fallback on the security side, but minor problems in daily use will no longer be repaired, and can only be tolerated by bypassing or downgrading operational habits.
| Stage | What can be obtained | The meaning of scheduling |
|---|---|---|
| Routine patch period | Functional defects and security patches | Can stay on the current version and update at a regular pace |
| Only security patch period | Only security patches | Plan migration, put the big version upgrade in the window |
| Support complete termination | No more updates will be released | It is necessary to upgrade, and the risk exposure begins to accumulate |
It is very simple to judge your position: find the big version you are in on the roadmap, compare the two dates, and follow the section you fall into.
The order of window priority
The order of the window is arranged according to 'risk × impact area', not according to the newness of the version number. The first step is to group the sites: sites with small content volume and short conversion paths should be done first to verify whether the upgrade process itself is feasible; the second step is to arrange the business key sites, avoiding the peak period of content release and promotion; the third step is the archive-type sites that are almost no longer updated, which can wait until the first two steps have completed the process.
The selection of the time window is also important. The upstream usually has a fixed security release rhythm, such as a certain Wednesday each month as the security release window; scheduling your own upgrade in the same batch as these fixed windows can reduce the number of shutdowns. Sites with ads and activity pages also need to avoid the activity period, as compatibility issues caused by an upgrade can increase the cost of handling by multiples if they coincide with traffic peaks.
Backup and rollback before the upgrade
Before upgrading, it is necessary to perform a full backup and not just backup the database: static files, upload directories, and templates must be included in the backup range. A full backup of data and static files is required to support real rollback. The backup must be verified for recovery after completion; backups that have not been verified cannot be used as rollback means.
The deployment method determines the rollback speed. Sites deployed using container images can roll back closer to 'roll back to the previous image' and complete in minutes; sites deployed using the panel one-click deployment or traditional environment deployment need to pull code and restore dependencies again, taking longer, so more buffer time needs to be reserved. When upgrading multiple sites in one batch, placing containerized sites at the front can expose process issues earlier.
High-risk capabilities should remain closed by default during the upgrade window. Site-wide operations such as backup, upgrade, and multi-site management should not be open to the public by default and need to be explicitly opened within the window and收回 upon the end of the window.When upgrading involving interface and login state changes, it is also necessary to tighten up: rotate the keys related to the access entry once, change the administrator's login password once; check that there are no entry points that can be concatenated in the sorting parameters of the list query, and the login credentials involved in the site switching should have an expiration mechanism or one-time tickets.The security fixes of the current version v3.6.6 are exactly for these two types of issues, which belong to the standard items of upgrade completion, not additional reinforcement.
Common questions
Can we wait another year for only the old versions with security patches?Can we wait depending on whether the functional issue is already affecting use. There is still a safety net, but the functional defects are no longer fixed, compatibility issues in the editing process will accumulate, and the extension and theme may leave the old version first.
Should we skip the intermediate version and upgrade directly to the major version?Judge according to the official support cycle. Versions still in the regular patch period can be kept first; versions that have entered the only security patch period should have their major version migration scheduled into the nearest window, rather than waiting for complete support to end before emergency upgrading.
What should we do if there is a problem on the day of the upgrade window?Immediately revert to the backup point, do not perform on-site repairs within the window. After the event, archive the compatibility issues, and before the next batch, first replicate on a small site, and then decide on the pace of progress.