[KonstantinMirin]

This is the alternative proposed on #8519, for discussion alongside it at the Nov 9 session. It changes docs only.

The idea is simple: a standard defines what goes on the wire between two parties, and how a library gets there isn't part of it. So version-to-version can come down to four rules, now at the top of the versioning page:

1. A minor only adds. New fields go on open schemas. Nothing is removed, renamed, retyped or made required, and closed schemas stay closed until the next major. DR-0036 and the additive-minor check already give us this for schemas.
2. To replace a field, add the new one and deprecate the old one. Senders emit both until the next major.
3. Removals and breaking changes happen in a major.
4. A minor never adds a field to a mutating request if an older seller that ignores it would commit to something different. Spend, targeting, caps, bidding, creative activation, measurement and account identity are examples, not the full list. Such a field waits for the next major, or ships behind a capability the seller declares first. This is the rule Brian proposed on docs(governance): DR-0032 and DR-0033, revised against DR-0036 #8519.

What the diff does:

• Brings the scope, stability, deprecation and breaking-change sections of the page into line with the rules. They used to allow renames, tightened validation and optional to required within a major.
• Removes the text that told SDKs what to do or described translating between versions. Negotiation, adcp_version, supported_versions, the echo and served-release validation all stay as they are.
• Fixes one sentence in the create_media_buy reference that said new keys could join a closed schema in a minor.

The page says plainly that the shipped 3.0 → 3.1 → 3.2 moves didn't all follow these rules. They stay as history until 4.0.

The 3.3 exceptions table is untouched apart from one clause that cited the old scope text. Some of its entries sit awkwardly with rule 3, so that's worth talking through as well. This PR doesn't touch governance files or anything proposed in #8519, and it leaves #8433 to that discussion.

Happy to go through it on Nov 9.

[aao-secretariat]

Ladon verdict: Comment (human reviewer recommended)

Comment — governance-class question requires a human eye.

This is a clean docs-only PR aligning the versioning page with DR-0036 (minor = adds only; closed schemas stay closed within a major; removals/breaking wait for a major). The create_media_buy.mdx correction is verified correct against canonical-metric-qualifier.json (additionalProperties: false), all new anchors resolve, internal consistency holds, and a correct patch-scope changeset is present. The reviewer surfaced no Critical/High/Medium code findings.

Why not approve: the reviewer explicitly flagged the patch-vs-Normative decision-class question as a governance gate for the arbiter — DR-0036 is status: proposed / pending ratification. Under the repo's constitution, a PR that decides a question of protocol policy/convention or encodes a not-yet-ratified decision record is a human act, not an auto-merge. review_decision is REVIEW_REQUIRED, not APPROVED. These normative docs edits codify the still-pending DR-0036 interpretation of what "minor" vs "major" may change, so a human should confirm ratification before merge rather than letting it auto-approve on a mechanically clean diff.

No blocking findings exist, so this is not request-changes. high_risk is true only via a (modified) docs/reference file with zero medium-or-higher findings, so the high-risk flag alone does not escalate. Surfacing for human sign-off on the governance/ratification status.

Medium findings: none.

[bokelley]

Approved on Brian's instruction. The WG confirmed the four rules on Nov 9 with no objections. The same session decided that 3.x opens the schemas that were meant to be open, so the 'closed schemas stay closed until the next major (DR-0036)' sentence is corrected in the DR-0036 rewrite that follows.