Use both. A regular patch cadence gives users a predictable rhythm for ordinary fixes, and an out of band release path handles critical security issues that cannot wait. Publish the cadence and the criteria for breaking it, so customers can plan and trust you.
What a mature project does
The Kubernetes project documents its approach on the patch releases page. It states that its typical patch release cadence is monthly, that it is commonly faster, one to two weeks, for the earliest patch releases after a new minor release, and that critical bug fixes may cause a more immediate release outside the normal cadence. It also says it aims not to release during major holiday periods.
That is a useful template: a default rhythm, a stated exception, and a note about timing.
Comparing the approaches
| Approach | Strength | Weakness |
|---|---|---|
| Only scheduled | Predictable for users and testers | A serious fix waits for the next date |
| Only ship when ready | Fast for urgent fixes | Constant churn, users stop keeping up |
| Scheduled plus out of band | Predictable and responsive | Needs clear criteria and discipline |
Steps to set it up
- Choose a cadence your team can sustain. Monthly is common, but pick what you can test.
- Write down what qualifies for an out of band release. For example, a vulnerability that is exploited, or that is rated critical and reachable in a default configuration.
- Name who decides, and how quickly. A single accountable person with a backup avoids debate during an incident.
- Publish the schedule with next dates and the criteria in your security policy.
- Announce out of band releases through the same channel as scheduled ones, with a clear label.
- Review quarterly: how many out of band releases were there, and were they justified?
Effects on customers
Customers who run your software in regulated environments often schedule their own change windows around yours. A predictable cadence lets them plan. An unexpected release is disruptive, so use it only when the risk of waiting is greater.
Pitfalls
- Calling every fix urgent, which teaches users to ignore out of band notices.
- Never using the exception, so a real emergency waits.
- Changing the cadence without telling anyone.
- Bundling large features into patch releases, which defeats the safe update promise.
Pair it with support rules
The cadence says when fixes ship. The support policy says which lines receive them. Publish both together.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fresh disclosure reaches the components you use, which is the kind of event that justifies leaving the schedule.
Safeguard's zero-day discovery and inventory matching help you see when an upstream out of band release affects you. A free scan is at gold.safeguard.sh/scan.
Quick check
Is a monthly cadence the standard?
No. It is what Kubernetes documents for its own project. Choose a cadence that fits your team and users.
What qualifies as out of band?
Define it in advance, for example an exploited or critical reachable vulnerability, and publish the rule.
Sources
Last reviewed: 19 October 2026.
