Node 26 reminded me runtime upgrades are calendar work

Runtime releases keep moving whether a project is ready or not.

Waiting for support to expire turns one upgrade into container, CI, native dependency, build-script, local-dev, and package work at the same time. A calendar keeps those failures separate.

A practical sequence is:

1. add the candidate runtime to CI
2. fix failures while the old runtime still works
3. run the scripts people forget
4. deploy a preview or canary
5. switch production
6. keep rollback available while the new line settles

The risky edge is usually between Node, V8, OpenSSL, native addons, and old build assumptions. A container may run while a database driver, watcher, or serverless default changes behavior.

Write the target in every place that controls it. CI, Docker, developer setup, and package metadata should agree:

{
  "engines": {
    "node": ">=26 <27"
  },
  "packageManager": "pnpm@10.0.0"
}

The release note is less important than the maintenance habit: know where the runtime runs, test the next line before the deadline, keep the upgrade narrow, and leave the system easier to move next time.