After the PHP version enters the stage of only fixing security issues, when should the site be upgraded at the latest?
After the PHP branch enters the stage of only fixing security issues, the latest deadline for the site to complete the major version upgrade is the end of security support for that branch, for example, security support for 8.2 ends on December 31, 2026. A more practical judgment is to treat the deadline as a bottom line rather than a plan; when entering the only security stage, the upgrade schedule should be initiated because the later it is done, the smaller the available patch window is.
How to read the two phases of the official lifecycle
PHP's support policy is clear: each branch is actively supported for two years since its official release, during which defects and security issues will be fixed and released with regular point releases; after the active period ends, the branch will receive another two years of support, but only for critical security issues.
The difference between the two stages is very significant in actual operations. During the active period, you can wait for routine point releases, and compatibility issues and non-critical defects will be addressed together; after entering the security-only phase, point releases are arranged as needed, and only security fixes will be released, and issues encountered by the business side must be borne by themselves. Therefore, 'still receiving patches' does not mean 'still in the support period'.
The deadline window of each branch
As of the current statement on the official support page:
| Branch | Active support ends | Security support ends |
|---|---|---|
| 8.2 | 2024-12-31 | 2026-12-31 |
| 8.3 | 2025-12-31 | 2027-12-31 |
| 8.4 | 2026-12-31 | 2028-12-31 |
| 8.5 | 2027-12-31 | 2029-12-31 |
The branch in the only security stage, the remaining time is its patch lifespan. 8.2 is now in this stage, and security support will end by the end of this year. Sites still running on 8.2 need to complete the migration within this year.
Three things to verify before upgrading.
The first is extensions and dependencies. List the actual extensions used by the site and confirm each one is available in the target major version; also check the minimum version requirements for frameworks and libraries, as many compatibility issues arise from dependencies rather than the code itself.
The second is the difference in behavior and regression. There are often semantic changes between major versions, and it is not enough to just check if the page is normal. You need to run the main chain of order, login, upload, form submission, etc., and observe the error logs for a period of time.
The third is the way caching and running services take effect. The loading time of opcode cache and user configuration files is easy to go wrong after version switching. After switching versions, confirm that the actual running worker is using the new interpreter, and restart all processes if necessary. Do not let some processes continue to run the old version.
The deployment method affects the cost of upgrading.
The same runtime environment replacement shows a significant difference in workload under different deployment methods. Switching PHP versions in Baota panel or aaPanel is an interface operation, it can be rolled back, and there is a version list;The LNMP command-line deployment requires the installation of the target version manually and adjustment of the site configuration; Docker image deployment modifies the image tag and orchestration file, providing stronger environment consistency and direct rollback.AnQiCMS is developed based on GoLang, the technology stack is GoLang plus Iris framework and GORM, the runtime does not require a PHP interpreter, therefore there is no part of the workload that frequently changes the runtime environment according to the PHP lifecycle;The PHP application is still running on the same server, schedule separately according to the above window.
Common questions
What will happen if you continue to run the old version after the end of security support?New vulnerabilities will no longer have targeted patches, and the exposure surface of the site will increase linearly over time; the operating system source may also stop providing this version, at that time, it will be difficult to continue with basic dependencies.
Can you jump directly from 8.2 to 8.5?Yes, but don't expect to succeed in one go. Jumping across multiple major versions means that you need to digest several rounds of behavioral changes at the same time, and the safe way is to verify the cross-version path in the test environment, confirm that there are no blockages before directly going to the target version.
What security actions do you need to take after the upgrade?Answer: Review the configuration items related to the operating environment, including the error reporting switch, upload limits, and session configuration, and update the site credentials as needed to avoid continuing to use old configurations exposed during the switching process.