Both patterns exist. Go and Kubernetes describe a roughly monthly patch cadence with out of band releases for critical issues. PHP says security fixes only branches get releases on an as needed basis. Dependents should learn which pattern each project uses, because it decides how long a known fix can wait.
What three projects say
Each project documents its own pattern.
| Project | Stated pattern |
|---|---|
| Go | Public track security fixes go in the next scheduled minor releases, which occur roughly monthly. Private track fixes are held for the next scheduled minor release, with a pre-announcement 3 to 7 days before |
| Kubernetes | Typical patch cadence is monthly, with critical fixes possibly releasing immediately, outside the normal cadence |
| PHP | Branches in security fixes only get releases on an as needed basis |
Both the Go and Kubernetes pages also describe schedule exceptions. The Go policy includes an urgent track, and Kubernetes says critical bug fixes may cause a more immediate release.
Trade-offs
A fixed cadence is predictable. Users can plan a monthly update window, and the project can batch changes and test them together. The cost is that a known fix may wait until the next date, unless it qualifies for an exception.
As needed releases get fixes out when they are ready, but users have to watch for them. There is no calendar slot to plan around, and a quiet month can mean no problems or just a missing announcement.
What dependents should do
Match your update routine to the pattern.
- For scheduled projects, add the release dates to a shared calendar and reserve time the days after.
- For as needed projects, subscribe to the announcement list and set an alert for a new release.
- For both, treat a security pre-announcement as a prompt to prepare, not as the fix itself.
- Keep a rule for out of band releases: who is paged, who approves, how fast.
- Note each project's pattern in your dependency register.
- Test the update path regularly, so an urgent patch is a routine change.
What maintainers can do
State your pattern in the security policy in one sentence: monthly on a given week, or as needed with notice on a given list. Mention how an urgent release differs. Users cope well with either pattern if it is written down.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how monitoring reacts when something changes, and think about which of your dependencies need a calendar slot and which need an alert.
Quick check
Is a monthly cadence slower than on demand?
It can be, except where the project has an exception for critical issues, as Go and Kubernetes describe.
What does a pre-announcement tell me?
That security fixes are coming in a named release, and which components are affected, so you can prepare.
Where do I find a project's pattern?
In its security policy or release documentation.
How Safeguard helps
Safeguard's asset discovery and continuous monitoring can show which services run which versions, and its SBOM and dependency scanning check those versions against known advisories. Reachability analysis helps you rank what to fix first. Autonomous remediation with fix pull requests is off by default, with every category on Manual. The free scan is a low-effort place to start.
Sources
- The Go Project, Go Security Policy: tracks and cadence. Fetched 19 October 2026.
- Kubernetes, Patch Releases: cadence and critical fixes. Fetched 19 October 2026.
- PHP Group, Supported Versions: security fixes only definition. Fetched 19 October 2026.
Last reviewed: 19 October 2026.
