compatibility_date is a runtime pin; bump it on purpose, alone

The answer. Cloudflare fixes runtime bugs and ships behavior changes behind dates, not versions. compatibility_date freezes your Worker on the semantics that existed on that day; Cloudflare commits to keeping old dates working. That is why C3 stamps today's date at scaffold time and why the value then sits untouched for a year. Treat it like a dependency major bump: read the compatibility-flags changelog for every entry between your date and today, bump in a commit that changes nothing else, deploy, and watch. If one change is unwanted, keep the new date and disable that single behavior with its no_ flag, so the pin stays readable.

The pattern.

// wrangler.jsonc
{
  "compatibility_date": "2026-09-01",
  // Explicit flags survive a date bump; the comments say why each one exists.
  "compatibility_flags": [
    "nodejs_compat",                 // Node APIs + polyfills (v2 semantics since 2024-09-23)
    "global_fetch_strictly_public"   // see worker-fetch-own-zone-error-1042
  ]
}

git commit -am "chore(worker): bump compatibility_date 2026-04-01 -> 2026-09-01"   # nothing else in the diff
npx wrangler deploy && curl -fsS https://api.example.com/health                 # then wrangler tail for 10 minutes

Watch out.

nodejs_compat on a date before 2024-09-23 gives you the old v1 behavior; a date after it silently upgrades to v2. That alone can change how packages resolve.
Named environments inherit the date, but if you override it in one env block you have two runtimes in one repo.
Local dev honors the date too, so a bump that breaks something breaks wrangler dev first. Good: that is where you want it.