Only leave security fixes and not stop supporting, when should the scheduling of the runtime environment be?
After the PHP version enters the stage of only security fixes, what should be the timeline for scheduling the site runtime environment - the answer is to calculate from the expiration of active support, rather than from the day of final cessation of maintenance.The official version support page on the day's table, the active support for PHP 8.2 ends on December 31, 2024, and the security support ends on December 31, 2026;PHP 8.3 active support ends on December 31, 2025, security support ends on December 31, 2027;PHP 8.4 is actively supported until December 31, 2026, and securely supported until December 31, 2028;PHP 8.5 is actively supported until December 31, 2027, and is securely supported until December 31, 2029.Many teams write the schedule in the last column before that day, resulting in the entire window being on a branch that only fixes security issues.
What kind of issues does the difference between two-phase support fall on
| Stage | What will be fixed | What will no longer be fixed | What phenomena the site will encounter |
|---|---|---|---|
| Active support | Functional defects and security vulnerabilities | None | Compatibility issues have official patches to follow |
| Only security support | Security vulnerabilities | Functional defects, dependency adaptation | Extended errors can only be bypassed, behavior differences will no longer be changed |
| Maintenance has stopped | None | None | No patches will be released for new vulnerabilities |
Differences are not visible in everyday life, but once encountered, they appear in clusters: compatibility issues with new databases or extensions will no longer be repaired by anyone; a dependency library changed its behavior, and the official branch will no longer follow up; while security fixes will still be released regularly, so the phrase 'still receiving patches' is easily misinterpreted as 'still supported'. When judging the schedule, it is more practical to regard only security support as expired.
Which date should the schedule be traced back from?
Using the end date of active support as the trigger point, leave enough preparation time in advance: first verify the performance of the program and extension in the new version in the test environment, then schedule the maintenance window, and finally make the formal switch. The runtime version and program version should be scheduled together, as their expiration dates are often out of sync. Handling them separately will cause a line to remain on the old branch for a long time.
The deployment method of the self-built system determines the fallback means. For Docker image deployment, fallback only requires switching back to the previous image tag, provided that the historical tags are still available; for one-click deployment using Baota panel or aaPanel, fallback depends on panel backups and site directory snapshots; for manual LNMP deployment, fallback relies on your own configuration and database backup. It is also necessary to review the default listening port and reverse proxy rules after switching to avoid not being accessible from the external network after the upgrade is completed.
Backup and regression preparation before the upgrade
You must back up both data and static files; if either is missing, it is not considered a complete backup. Attachments uploaded, thumbnails generated, and theme templates all belong to the static file section. Sites that only back up databases are most commonly found to be empty in this area during recovery. After the backup is completed, it is really necessary to restore it to an isolated environment to see if it can be brought up. The practice of only generating files without verification will expose risks only when an incident occurs.
Regression checklist written by link: background login and captcha, article creation and publication, column and list page, image upload, form submission, interface reading. Note the performance before each upgrade, compare item by item after the upgrade, and first judge whether the change is due to version behavior change or configuration omission.
Items to check after going online
At least three things to check after the switch is complete: the reported runtime environment version of the program is indeed the new version; there are no new compatibility alerts in the error log within a business cycle; the rollback path is available, and the mirror tag or backup file can still be found. Write these three into the change record, and the next schedule will have a reference time cost.
Common questions
Why are you in a hurry to upgrade when the version that only supports security is still releasing security patches?Because the functional defects and dependency adaptation are no longer fixed. Security patches only solve the disclosed problems and cannot handle the changes in extended behaviors and compatibility breaks for you.
Can you only upgrade the runtime environment without upgrading the program?Yes, but it depends on the version support range of the program. The compatibility with old files will also be terminated, and both lines need to be confirmed together.
How early should the scheduling be prepared?It depends on whether you can complete a full recovery drill before the due date. Verification of the test environment, application for maintenance windows, and acceptance of backups will all take time.
What should I do if there is no backup?First, perform a backup of the data and static files, verify the recovery, and then proceed with any upgrades. The loss caused by upgrades that cannot be rolled back is usually greater than the delay in upgrading.