It is more stable to upgrade on which day of the week when updating the description only includes security fixes.
Update description should only mention when to upgrade on which day for safety repairs? Do not schedule it on Friday or before holidays, choose a working day morning with someone on duty for safety, Tuesday or Wednesday is usually the most appropriate: There is a whole day to deal with problems, the day can be rolled back, and there is also room for review. The update description for 'safety repair' and regular feature update scheduling logic is different, the risk window of the safety version starts from the announcement release.
Functional version and security version are not the same thing
Function versions have a predictable release date. The Joomla official has written in the release news that “Joomla! 6.2 (general availability) will be released on or about 13th October 2026.“, such dates allow operation and maintenance staff to schedule them into the plan schedule.The secure version is often opposite: Drupal's official security alert states, 'PHP has announced a critical PHP security release for Wednesday, October 21, 2026, at 14:00 UTC. Reserve time to update PHP as soon as the release is available.' The tone is to reserve time and update PHP as soon as the version is available.
The consequences of mixing the two are very specific: placing security fixes in the regular releases at the end of the quarter is equivalent to leaving a gap between the announcement and actual handling, during which the exposure period is public.
Which time period should the window be placed?
When scheduling, filter time periods according to four constraints:
- Avoid Friday and before holidays: the cost of fault handling spanning the rest period is the highest.
- Choose off-peak business hours but have someone on duty: although the traffic is low at midnight, the rollback is slower when there is no one on duty.
- Avoid backup tasks: when the upgrade window collides with automatic backup, the recovery point may be in a semi-updated state.
- Leave time for review: No other changes are scheduled on the upgrade day to facilitate locating the anomaly from which change.
Following these four points, the morning of weekdays is the most common landing point; if the announcement gives a clear deadline for high-risk patches in the operating environment, the preparation actions should be completed in advance by reversing the execution time of the announcement.
Preparation before upgrade
Three things must be done before the window: a complete backup, a clear rollback point, and an executable verification checklist. The backup covers the database and static files, the rollback point records the current version number and configuration location, and the verification checklist at least includes the rendering of the homepage and list page, article page and illustration, in-site search, message and form submission, background login and permission.
AnQiCMS backup and recovery supports data and static files to be processed together, in conjunction with scheduled publishing and pending publishing status, which can hold new content during the upgrade period first, to avoid simultaneous content changes in the update window. It is also recommended to confirm the current version of the site during the preparation phase to avoid missing intermediate configuration changes when upgrading across multiple old versions.
Verification and record after upgrade
After the upgrade is completed, verify items one by one according to the list, and then do three more things:
- Review the configuration related to security has not been temporarily changed, including authentication methods, captcha, and content review switches.
- Sample the external visible page, confirm there are no abnormal jumps or implanted content.
- Record the date, target version, executor, and verification results in the version ledger.
The repair of credential-related issues, the final actions are not just to supplement the version. AnQiCMS v3.6.6 (2026-10-08) fixed two high-risk issues of list sorting parameter injection and the site switching login credentials being forgeable, the upgrade instructions also suggest rotating the site signature key and changing the administrator password; such a requirement of 'repair and rotate the key' should be written into the change log of this time, otherwise, no one will remember after a week.
Common questions
Is it necessary to upgrade the security repair on the same day?Check the urgency of the announcement and the exposure surface of the site. Provide a clear deadline or handle the announced exploitation as soon as possible; for those without a deadline, they should also be completed within the same work week and not delayed to the end of the month.
What should you do if there is no test environment?Create a copy in an isolated environment using the backup, run the verification list first, and then go to production; this step is much cheaper than rolling back on the production site.
Can we combine the security upgrade and feature upgrade into one?Yes, but you need to confirm that the functional changes will not interfere with the judgment of the security verification. It will be more difficult to locate exceptions after merging, and the verification list needs to cover two types of changes.