There are only branches of script languages for security repairs, so the operator needs to pay attention to which two dates?
After the script language branch enters the stage of only receiving security fixes, the two dates that the site operator needs to pay attention to are the date of stopping active support and the date of stopping security fixes. Once the former arrives, functional defects will no longer be repaired, only key security issues will remain; once the latter arrives, even security patches will no longer be provided. The time between the two dates is the migration window, treat it as a 'still usable' margin, which is the most common time misjudgment
Differences in the definitions of the two support stages
The definition on the official version support page is clear on the day: the scope of the active support stage is 'Reported bugs and security issues are fixed and regular point releases are made', that is, all defects and security issues will be repaired and small versions will be released regularly;A release that is supported for critical security issues only. Releases are only made on an as-needed basis
The difference is in two sentences: one is 'critical', where common defects no longer move; the other is 'as-needed', where the publishing version does not have a fixed rhythm, you may not get the small version, and you can only migrate directly to the next branch.
The two dates to keep an eye on
| Branch | Only the closing specifications of the security phase are repaired | The actions of the operator |
|---|---|---|
| An earlier branch | Verify that the security support ends on December 31, 2026 on the day | The migration plan should be arranged the same year |
| The middle branch | Security support ends on December 31, 2027 | Enter the observation period, verify compatibility |
| Newer branch | Security support ends on December 31, 2028 | Routine maintenance is sufficient |
| Latest branch | Security support ends on December 31, 2029 | Focus on the end date of active support |
There is an earlier 'end of active support' date for the same branch. The time you really need to get to work is not the security support deadline, but the end of active support: from that day on, you have to bear compatibility issues and functional defects yourself, and wait until the security support deadline to migrate, usually only a few weeks are left to do a complete regression.
The time difference between the announcement and the fix
The upstream will send a preview in advance and ask for reserved time. In the other document checked on the same day, the security release window was announced in advance and stated 'Reserve time to update PHP as soon as the release is available', directly naming the preparation period to the webmaster. When seeing such announcements, the correct reaction is not to wait for the patch to come out and then look, but to prepare the recovery point and test environment between the announcement day and the window day.
A few days between the preview and the landing are often the most cost-effective preparation time of the year: at this time, there is no pressure from failures, and decisions do not have to be made in a few hours.
Collaboration on the side of the operating environment
The口径 on this side of the self-built program is different. AnQiCMS is a Go language program, the delivery form is compiled binary plus configuration file, the operating environment mainly depends on the deployment method: when container deployment, the operating environment goes with the image, when panel deployment, it goes with the version provided by the panel, and the port and reverse proxy configuration remains unchanged at the 8001 level.
This means that the risk of 'language branch disabling' is manifested on the self-built side as the outdated mirror base layer, the processing method is to rebuild the mirror instead of waiting for the upstream to release patches. It is more reliable to write the base image version and the rebuild frequency into the inspection items than to remember the deadline of a certain language.
Common questions
Q: Can the branch only repaired in the security stage continue to run in the long term? A: It can for a short period, but you have to bear the functional defects, and the security patches become on-demand release, with an uncontrollable waiting period.
Q: Does migration have to be across major versions? A: Not necessarily. First, check the compatibility and dependencies of the target branch, and crossing one version is usually less risky than accumulating two versions.
How do you turn two dates into actionable items? Answer: Set a reminder on the calendar for 'End of active support one quarter before' and schedule a rollback drill at the same time.