Every Drupal site owner with contrib modules installed knows the moment: an advisory email lands, the module page shows both a security release and a newer minor version, and the maintainer stares at the update screen trying to decide whether to apply the tiny patch now or schedule the bigger upgrade for next week. Getting this fork wrong in either direction is expensive — patching hastily can break a site on a Friday afternoon, while waiting lazily can leave a known hole open for a month. This article turns the fork into a routine: a one-sentence distinction, a reusable decision table, the rollback question that settles ties, and a habit of writing the decision down. It sits naturally beside the what belongs on a Drupal maintenance checklist, where this call is just one disciplined line among nine.
The core distinction in one sentence: a patch changes as little as possible to close a specific hole, while an upgrade takes everything the module authors shipped — features, refactors, and their own new risks.
The Difference In One Sentence
Drupal’s security team publishes advisories in two shapes. A security release of your installed branch — say moving from 3.4.1 to 3.4.2 — is built to be small, reviewable, and safe, containing the fix and almost nothing else. A newer minor line — 3.5.0 — contains that same fix plus every feature and refactor the maintainers merged since, which is exactly what makes it both tempting and riskier. The psychological trap is that the bigger number feels more responsible, like buying the full service instead of the oil change. But the professional question is never “which is newer” — it is “which change can this site absorb today, tested, with a rollback that works.” Everything below is machinery for answering that question in ten minutes instead of ten days of dread. Advisory specifics live in the Drupal security advisory feed, which is the canonical source every maintainer should scan rather than relying on second-hand summaries.
A Decision Table You Can Reuse
Score the situation on four axes and the answer usually announces itself. One: severity of the advisory — a remotely exploitable hole on a public form is a patch-now case almost regardless of the other axes. Two: exposure of the site — an intranet with two editors tolerates delay that a commerce site cannot. Three: distance to your next maintenance window — if the window is tomorrow, patching today and upgrading next week is usually the right split; if the window is six weeks out, the patch cannot wait inside it. Four: module criticality — a patch to a caching integration fails differently than a patch to the module rendering your checkout. Worked application: a membership site maintainer sees an advisory on the module powering member renewals. The module is critical, the site is public, the next window is three weeks out — the table says patch today, plan the 3.5 upgrade for the window with proper staging. She patches in forty minutes, and the upgrade three weeks later ships with a regression checklist instead of anxiety. That staging habit is the same one behind the regression checklist before a minor release, and it is what makes the bigger upgrade safe enough to schedule rather than fear.
The Rollback Question That Decides
When the table ties, one question settles it: if this change breaks the site at the worst possible hour, how do I get back — and how long does that take, honestly? A patch applied to a site with current backups and a staging copy can be rolled back in minutes, which is why patching-now is usually cheap. An upgrade rolled out without a database backup taken at the moment of deployment, or to a module whose downgrade path is known to be messy, has a rollback measured in hours of scrambling — which is why upgrades deserve their own window and their own plan, like the one in planning a major upgrade before you start. The discipline that protects both paths is boring and non-negotiable: a fresh backup before every apply, a staging rehearsal for anything bigger than a point release, and a written note of what was done, when, and why. Sites that keep those three habits rarely debate this article’s question for long; sites that skip them debate it every advisory.
Documenting The Decision So The Next Dev Agrees
The final habit costs a paragraph and pays for itself the first time a colleague, a client, or a future-you disagrees with the call. Write a short decision note wherever the site keeps its run-log: the advisory ID, what was applied and when, which axis of the table drove the choice, and when the deferred upgrade is scheduled. This turns a judgment call into a record. When the client asks why the site was patched on a Tuesday instead of waiting for the window, the answer is a sentence instead of a reconstruction. When the next advisory lands on the same module, the history shows whether this module’s patches have been gentle or cursed. And when a new maintainer inherits the site, they inherit decisions instead of mysteries. None of this is glamorous — but a Drupal site maintained this way accumulates trust in exactly the same way it accumulates updates: quietly, every month, without drama.
If you are behind on both fronts, the order is fixed: close the open holes first, then schedule the upgrade for the next proper window. The worst outcome is the reverse sequence — a feature upgrade landing on a site that still has a known hole open, which combines the risk of both decisions with the benefit of neither. Maintenance is forgiving about timing and unforgiving about order.
If you take one rule: patch like the hole is open, because it is; upgrade like the feature can wait, because it can. Same advisory, two different clocks — and the table tells you which one you are on.