What we actually adopt from a Craft release, and what we ignore

Every Craft release arrives with a changelog and a quiet expectation that you'll read it, get slightly excited, and refactor something. We read them. We refactor almost nothing.

That isn't conservatism for its own sake. We host most of what we build, which means every upgrade decision is one we personally have to be awake for at seven in the morning if it goes badly. Over time that's pushed us into having a written policy rather than an instinct, and the policy is simple enough to set out.

Adopt immediately: anything that reduces what we maintain

If a release moves something out of our code and into the CMS, we take it the same week. Every line of custom code we delete is a line nobody has to understand in three years, and a line that can't break during somebody else's upgrade.

This is the category most teams under-rate, because deleting code doesn't feel like progress. There's nothing to demonstrate at the end of it and no new capability to point at. It is nonetheless the only kind of progress that compounds — a codebase that shrinks while the site does more is a codebase that will still be maintainable when whoever wrote it has moved on.

The practical version: when Craft absorbs something we'd previously built by hand, we schedule the removal into the next hosting window rather than waiting for a reason. The reason never arrives on its own.

Adopt on the next build: anything that changes the shape of a content model

New field behaviour, new relationship options, new ways of structuring entries. These are frequently the most genuinely useful things in a release, and we will not retrofit them into a site that already works.

A content model is a contract with the person who edits the site every day. They've learned where things are. They've built habits and probably written their own notes. Rewriting that contract because a tidier option has appeared is our problem to be excited about, not theirs to absorb — and the benefit accrues almost entirely to us.

So it goes into the next new build, where the editor is learning the model for the first time anyway and the better version costs them nothing extra to learn.

The exception is when the old approach is actively causing the client trouble. If an editor is routinely doing something awkward because of how we modelled it two years ago, and a release makes that unnecessary, we'll quote the change and explain why. That's a fix, not an upgrade.

The question isn't "is this better?" It's "is this better enough to justify re-teaching somebody their own job?"

Wait one version: anything that touches the editor experience

Control panel changes ship well and they ship into the middle of somebody's Tuesday. A client who has learned where a button is does not want a better button. They want the button, in the place it was, so they can publish the thing they came to publish and get back to their actual job.

So we let a version settle. We watch what the Craft community reports in the first few weeks, because the issues that matter tend to surface from people running unusual configurations rather than from the release notes. Then we move sites over deliberately, in batches, and we tell the editors before we do it rather than after.

The cost of waiting a few weeks is close to zero. The cost of being the client who discovers a regression is a phone call, an apology, and a dent in the assumption that we know what we're doing.

Skip entirely: anything that only benefits us

There is always something in a release that would make our development marginally more pleasant and make no observable difference to the studio we're working for or the client paying for it.

These are the easiest changes to justify internally and the hardest to defend to anyone else. A developer-experience improvement is a real thing and it does eventually show up as speed, but "eventually" is doing a lot of work in that sentence, and in the meantime somebody is paying for a change they'll never see.

We skip them on existing sites and adopt them on new ones, where the cost is genuinely zero.

The exception that overrides all of the above

Security. If a release fixes something exploitable, it goes out immediately across every site we host, in the same day where the severity warrants it, regardless of what else is happening.

This is the specific reason Craft and plugin updates within your major version are included in hosting rather than billed as amends. If patching requires an approval, it requires someone to be available and to decide it's worth the money this month — and in practice that means it gets deferred, then skipped, then forgotten. Making it included removes the decision entirely.

Major versions are projects, not patches

Everything above concerns point releases within a major version. Major version upgrades are a different category and we treat them accordingly: quoted, planned, scheduled, tested on a copy first.

Templates change. Plugins need compatible versions and occasionally one hasn't shipped yet, which turns a two-day job into a decision about whether to replace a dependency. There's a deployment window, and there's someone available afterwards in case something surfaces that testing didn't.

Pricing that as routine maintenance would mean either doing it badly or quietly not doing it at all. Both are worse for a client than an honest quote and a date in the calendar.

What this looks like from the outside

If you're a studio we build for, almost none of this should ever reach you. Sites stay patched. Nothing changes underfoot for your client without warning. Occasionally we'll mention that a new build will use a slightly different approach to something, and that's usually the whole of it.

The net effect is that our sites tend to run a little behind the newest available thing and a long way ahead of the average. Given that the average includes a great many sites two major versions out of date because upgrading was never anyone's specific responsibility, we think that's comfortably the right end of the trade.