Keeping Updated

Falling behind on updates is how a stable tool becomes a fragile one — not through any single failure, but through the slow accumulation of “I’ll deal with that later” across dozens of small version bumps. The specifics differ between professional CI/CD tools and personal tools, but the underlying habit is the same: update on a cadence, not in response to a crisis.

Jenkins & Concourse (general approach)

• Weekly Security releases get priority. Jenkins in particular ships frequent security advisories; those get applied on their own schedule, separate from routine version bumps.
• Plugin updates in small batches, not all at once. Updating every plugin simultaneously makes it hard to tell which update broke something if a job starts failing. A handful at a time, with a working pipeline run in between, keeps the blast radius small.
• Pin versions in source control. Whether it’s a plugin list, a base image tag, or a fly CLI version, pinning explicitly (rather than always-latest) means an update is a deliberate, reviewable change instead of something that silently shifts under a job.
• Read the changelog before the “upgrade now” prompt. Especially for anything with a plugin ecosystem — a minor version bump can still be a breaking change for a specific plugin.

Obsidian

• Automatic updates for the core app; deliberate, one-at-a-time updates for community plugins, since plugin compatibility with a new Obsidian release lags slightly and inconsistently.
• Before updating a plugin that touches vault structure (Breadcrumbs, Dataview), a quick skim of the release notes for breaking changes — a vault with years of notes in it is not something to risk on a blind update.

OmniFocus

• Updates land automatically through the App Store; the only real maintenance habit is reading release notes for changes to perspectives or automation, since those are the features I’ve built the most workflow around.

Homebridge

• Plugins updated deliberately, one at a time, with a check that the affected accessory still responds afterward — a broken plugin update that goes unnoticed until an automation silently fails at 6am is a worse experience than the five minutes it takes to verify.
• Node.js and Homebridge core kept current but not bleeding-edge — a version or two behind latest, after the ecosystem has had time to surface any regressions.

Claude / Claude Code

• Release notes get a skim on update, specifically for anything that changes tool behavior or permission model — since Claude Code is operating directly on real repos, a behavior change here has a much higher blast radius than a UI tweak in a notes app.

The general pattern

Security patches get applied fast and separately from everything else. Routine version bumps happen on a regular cadence, in small batches, with changelogs actually read. Nothing gets updated for the first time in production, or in a vault, or on a device that matters — there’s always a way to see the update land somewhere lower-stakes first.