Filed from the work on #13779, which corrected only the page's concluding disclaimer. The rest of the page — and one page outside it — carry the same defect in the same direction, and were deliberately left untouched there to keep that diff scoped.
The defect
The repo's operative versioning rule today is the launch-window convention: every published @objectstack/* package sits in one Changesets fixed group (69 packages, check:changeset-fixed), and a breaking change ships as MINOR rather than burning a MAJOR. It is mechanically enforced by scripts/check-changeset-no-major.mjs, which is currently in its enforcing state (.changeset/pre.json is absent) and reports 559 pending changesets, 0 declaring a major. packages/spec/CHANGELOG.md shows 17.2.0's Minor Changes section carrying an entry marked **BREAKING**.
Three surfaces still tell customers the opposite.
1. content/docs/protocol/backward-compatibility.mdx — the SemVer table
The MINOR row's Guarantee reads "Existing code continues to work". #13779 added an overriding section at the page's conclusion, but the table itself is unqualified where a reader meets it first.
2. Same page — the Breaking Change Policy table and process
Every row of the breaking-change table maps to Version Impact: MAJOR; the process section ends "Breaking change ships in the next MAJOR version"; and the deprecation timeline's Phase 3 is "Removal (next MAJOR release)". All three are contradicted by shipped releases — 17.2.0 retired http_request_errors_total in a MINOR under ADR-0049, and 15.1.0 removed tenancy.strategy and tenancy.crossTenantAccess in a MINOR.
Also unverified on that page, and worth a look in the same pass: the Breaking Change Process claims a "Minimum 30-day community review period". No mechanism for it was found in the repo.
3. content/docs/releases/index.mdx — the Versioning policy section
Minor releases add capabilities without breaking existing metadata or code.
This is the same false statement on a second customer-facing page. ⚠️ That directory is fenced by AGENTS.md (never edited in a code PR), so it needs its own docs-only change — which is part of why this is a separate card.
Why it is worth a card
Same reasoning triage applied to #13779: this is what a customer reads to judge upgrade risk, and the version number is not the safety signal the pages say it is. The v17 release notes already say so plainly — "17.1.0 and 17.2.0 are minors by version number, not by blast radius" — so the drift is between the release notes and the policy pages, not inside the project's own understanding.
Not addressed here
#13779 covers the concluding disclaimer only and does not touch any of the above.
Generated by Claude Code
Filed from the work on #13779, which corrected only the page's concluding disclaimer. The rest of the page — and one page outside it — carry the same defect in the same direction, and were deliberately left untouched there to keep that diff scoped.
The defect
The repo's operative versioning rule today is the launch-window convention: every published
@objectstack/*package sits in one Changesetsfixedgroup (69 packages,check:changeset-fixed), and a breaking change ships as MINOR rather than burning a MAJOR. It is mechanically enforced byscripts/check-changeset-no-major.mjs, which is currently in its enforcing state (.changeset/pre.jsonis absent) and reports559 pending changesets, 0 declaring a major.packages/spec/CHANGELOG.mdshows17.2.0's Minor Changes section carrying an entry marked**BREAKING**.Three surfaces still tell customers the opposite.
1.
content/docs/protocol/backward-compatibility.mdx— the SemVer tableThe MINOR row's Guarantee reads "Existing code continues to work". #13779 added an overriding section at the page's conclusion, but the table itself is unqualified where a reader meets it first.
2. Same page — the Breaking Change Policy table and process
Every row of the breaking-change table maps to
Version Impact: MAJOR; the process section ends "Breaking change ships in the next MAJOR version"; and the deprecation timeline's Phase 3 is "Removal (next MAJOR release)". All three are contradicted by shipped releases —17.2.0retiredhttp_request_errors_totalin a MINOR under ADR-0049, and15.1.0removedtenancy.strategyandtenancy.crossTenantAccessin a MINOR.Also unverified on that page, and worth a look in the same pass: the Breaking Change Process claims a "Minimum 30-day community review period". No mechanism for it was found in the repo.
3.
content/docs/releases/index.mdx— the Versioning policy sectionThis is the same false statement on a second customer-facing page.⚠️ That directory is fenced by AGENTS.md (never edited in a code PR), so it needs its own docs-only change — which is part of why this is a separate card.
Why it is worth a card
Same reasoning triage applied to #13779: this is what a customer reads to judge upgrade risk, and the version number is not the safety signal the pages say it is. The v17 release notes already say so plainly — "17.1.0 and 17.2.0 are minors by version number, not by blast radius" — so the drift is between the release notes and the policy pages, not inside the project's own understanding.
Not addressed here
#13779 covers the concluding disclaimer only and does not touch any of the above.
Generated by Claude Code