Split compat date into release version and maximum compat date

[penalosa]

Fixes #6188

The daily release was writing a date 7 days into the future to supported-compatibility-date.txt, which was used for both the binary's maximum accepted compat date and the version string / npm compatibilityDate export. This meant the npm package exported a future date as compatibilityDate, which workerd then rejected.

Splits into two files:

• release-version.txt — the release date. Used for the version string (workerd --version) and the npm compatibilityDate export.
• maximum-compatibility-date.txt — the release date + 7 days. The maximum compat date the binary will accept.

The CODE_VERSION validation checks both the binary limit (MAXIMUM_COMPATIBILITY_DATE) and the clock time, preserving the original behaviour of rejecting future compat dates.

Also bumps the default npm patch version from 0 to 1 to avoid conflicting with releases already published over the next few days.

[ask-bonk]

Quick review

Clean split — the two-file separation correctly addresses the mismatch between the npm-exported compatibilityDate and the binary's maximum accepted compat date.

One stale reference: RELEASE.md (lines 7 and 11) still links to supported-compatibility-date.txt, which no longer exists after this PR. Consider updating those references to point to release-version.txt and adjusting the wording accordingly.

[ask-bonk]

I'm Bonk, and I've done a quick review of your PR.

This PR splits the single supported-compatibility-date.txt into two files — release-version.txt (for version strings and npm exports) and maximum-compatibility-date.txt (release date + 7 days, for the binary's compat date ceiling) — fixing the bug where the npm package exported a future date that workerd then rejected.

One issue found:

1. Stale documentation reference (low severity): RELEASE.md lines 7 and 11 still link to supported-compatibility-date.txt, which this PR removes. These become broken links. I posted a comment on the PR with suggested replacement text since the file isn't in the diff.

The rest of the changes look correct — the BUILD files, C++ source, tests, workflows, and CODEOWNERS are all consistently updated.

github run

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉

[vicb]

Look almost good to me :)

I would clarify the release version vs the date.

Was bonk comment addressed too?

I'll let other more familiar with the code base approve.

[penalosa]

/bonk I've addressed your review in 064895e

[ask-bonk]

Looks good. The commit updates the two stale RELEASE.md references from supported-compatibility-date.txt to release-version.txt and adjusts the surrounding wording to drop "compatibility date" in favor of just "date" — which is accurate since the file now holds the release date, not the maximum compat date.

This addresses the documentation issue I flagged in my earlier review. The wording is also slightly improved: line 7 no longer says "compatibility date" (which could be confused with the binary's max compat date), and line 11 matches.

One note for @vicb's open question about renaming to release-date.txt: that wasn't addressed in this commit, but it seems like @penalosa's reasoning (this is also the workerd --version output, so "version" is appropriate) is sound. The file serves double duty as the version identifier, not just a date.

github run