[bokelley]

Decision records on AdCP version handling, from #8373. Updated after WG Session C (2026-10-26).

What this PR carries

• DR-0034: accepted (WG Session C, 2026-10-26; dissent: none).
  • A request carrying only adcp_major_version is served the oldest supported release in that major: 3.0 for adcp_major_version: 3. A buyer that wants newer behavior sends adcp_version.
  • It replaces DR-0024's "Unpinned requests" paragraph; the rest of DR-0024 stands.
  • docs/reference/versioning.mdx (the "Omitted" rule, the major-only example, the in-house-client note) and the §4 table in specs/version-negotiation.md now state the rule.
• DR-0035: recorded. adcp_major_version and adcp.major_versions are deprecated through 3.x and removed in 4.0, writing down a decision the schema and docs already state.
• Docs reminder: the 3.3 release notes, the 3.2 → 3.3 upgrade checklist (row 32) and the migration guide's Deprecations section restate the 4.0 removal. A patch changeset is included.

Moved out

DR-0032 and DR-0033 were not ratified; they're parked until #8501 is settled. They now live in #8519 (draft), together with the LADON.md mandatory check and the constitution invariant that enforce DR-0033. As a result this PR no longer touches LADON.md or the constitution.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon is not auto-reviewing this PR because it modifies the review system itself (LADON.md). A human reviewer should review and merge this PR; Ladon resumes on subsequent PRs once these changes land on main.

[aao-secretariat]

Ladon is not auto-reviewing this PR because it modifies the review system itself (LADON.md). A human reviewer should review and merge this PR; Ladon resumes on subsequent PRs once these changes land on main.

[aao-secretariat]

Ladon is not auto-reviewing this PR because it modifies the review system itself (LADON.md). A human reviewer should review and merge this PR; Ladon resumes on subsequent PRs once these changes land on main.

[KonstantinMirin]

On DR-0032, DR-0033, and DR-0034: the translation layer solves a problem that the versioning rule should prevent.

adcp-client#3372 notes that 3.0 and 3.1 requests are valid in the 3.2 shape. The adapters exist for four 3.2 changes that weren't additive: bid_price to bidding, assignments to assignment_operations, delivery currency, and the account key. Every future change like these adds an adapter in every SDK, in both directions.

I propose one rule for minors instead:

1. A minor only adds. To change a field, add the new field and deprecate the old one.
2. While both exist, the sender fills both, so older receivers read the deprecated field and newer receivers read the new one.
3. If the new field expresses something the old one can't, it is must-understand, and an older receiver rejects the request instead of ignoring the field.
4. The next major removes deprecated fields. A change that fits none of these waits for it.

With that rule:

• DR-0033: replace "a pathway back for every change" with the rule. A reviewer checks one thing: whether the change is additive.
• DR-0032: SDKs negotiate the release and drop fields the peer's release doesn't define, generically from the schemas. No move adapters, no account-key reduce. The account-key case goes away with decision D on RFC (3.3, P10 of #8118): request_account, one pending-action shape, and buyer_agent_config naming #8280.
• DR-0034: with receivers that ignore unknown fields (DR-0009), serving the highest release is safe, as versioning.mdx and adcp-go already do.

The review rules in adcp-client-python#1563, adcp-client#3380, and adcp-go#591 already enforce DR-0032 and DR-0033 before ratification. I ask that they be marked pending this PR.

For 4.0, a stable core with modules keeps the rule sustainable. New vocabulary lands in a module's own version, so core has no reason to break.

[KonstantinMirin]

This PR proposes three rules for differences between 3.x minor releases. SDKs translate between them (DR-0032). Every change documents a way back to the previous minor (DR-0033). A request that only says "version 3" gets the oldest 3.x release (DR-0034).

DR-0034: yes, as a stopgap for 3.x, and I need to correct what I said earlier. I wrote that serving the newest release is safe because receivers ignore fields they don't know. That's wrong for some objects. 3.0 published them as closed, meaning a validator must reject any field it doesn't know, and later minors added fields to them. For example, the brand reference gained countries in 3.2. A 3.0 buyer that validates correctly rejects that response.

That's the underlying problem: some minor releases weren't purely additive. Translation in every SDK repairs that after the fact, and every new break needs more translation. I'd rather stop the breaks. #8502 adds one CI check that fails any change that removes something or adds a field to a closed object. Run against past releases, the check finds 79 such changes in 3.1 and 70 in 3.2, not counting experimental features. #8501 explains why our rules disagree: DR-0009 says schemas are open so that minors stay safe, while DR-0019 allows adding fields to closed schemas in a minor.

So I object to treating DR-0032, DR-0033 and the shared translation vectors (#8433) as settled. Please bring them back to the agenda.

[bokelley]

WG Session C (2026-10-26): DR-0034 is ratified: a major-only request (adcp_major_version: 3) is served 3.0, and adcp_major_version is deprecated for removal in 4.0. DR-0035 is recorded. DR-0032 and DR-0033 are not ratified: they're parked until #8501 (closed schemas in minors) is settled, after an objection from @KonstantinMirin. Please mark DR-0034 accepted and leave DR-0032/0033 proposed, or split them out, so this PR can merge. It changes LADON.md, so it needs a human merge.

[aao-secretariat]

Medium: supersedes: DR-0024 here, and the Decision says this "replaces only the 'Unpinned requests' paragraph of DR-0024" — but DR-0024 is not touched by this PR. Its ## Decision still reads: "A request with no adcp_version, or with only adcp_major_version, is served at the default or highest release" (DR-0024:25). Two ratified records now give opposite answers for the major-only case (highest vs oldest), and DR-0024 carries no marker that it was superseded. Per the records README, supersession keeps the file but adds superseded_by and the superseding record replaces the stale text. Update DR-0024:25 to point at DR-0034 (or restate the oldest rule) and add superseded_by: DR-0034 so a reviewer citing DR-0024 §Unpinned requests doesn't get the superseded answer.

[aao-secretariat]

Ladon verdict: Escalate to human review

Escalate — Breaking-class ratification requires human review.

This PR ratifies DR-0034 and records DR-0035, which governs removal of AdCP major version negotiation in 4.0 and changes the "oldest supported release" rule for major-only requests across versioning.mdx, version-negotiation.md §4, and the migration/release-notes docs. Per the repo's hard gate, a Breaking-class protocol change — even a clean one — is never auto-approved: ratification is a human act, and must escalate unless review_decision is APPROVED. Here review_decision is REVIEW_REQUIRED, so the gate stands.

Escalation reasons

• Ratification of DR-0034 / DR-0035 governs removal of major-version negotiation in 4.0 — a Breaking-class protocol policy decision requiring human ratification; review_decision is REVIEW_REQUIRED, not APPROVED.
• DR-0034 asserts it supersedes DR-0024's "Unpinned requests" rule, but DR-0024 is untouched and still reads "default or highest release," leaving two ratified records in direct contradiction with no superseded_by marker — a governance-record coherence gap a human should resolve before merge.

Medium findings

• governance/decisions/DR-0034-major-only-requests-are-served-the-oldest-release.md:10 — DR-0034 supersedes DR-0024 but leaves DR-0024's contradictory "highest release" rule unmarked.

The docs/spec changes are internally consistent (anchors, upgrade-row numbering, §4 table all resolve), the changeset is present and in-scope, and there is no schema↔docs drift. But the Breaking-class governance gate is semantic and prose-based, not satisfied by a clean diff.

Medium findings

• governance/decisions/DR-0034-major-only-requests-are-served-the-oldest-release.md:10 — DR-0034 supersedes DR-0024 but leaves DR-0024's contradictory "highest release" rule unmarked

Why human review

• Ratifies DR-0034 / records DR-0035 governing removal of major-version negotiation in 4.0 — a Breaking-class protocol policy decision requiring human ratification; review_decision is REVIEW_REQUIRED, not APPROVED
• DR-0034 claims to supersede DR-0024's 'Unpinned requests' rule but DR-0024 is untouched and still asserts 'default or highest release' — two ratified records contradict each other with no superseded_by marker

[bokelley]

Updated for WG Session C (2026-10-26), head 2866521:

• DR-0034 is now accepted (WG Session C, 2026-10-26; dissent: none). versioning.mdx and the §4 table in specs/version-negotiation.md now state the oldest-release rule.
• DR-0035 stays recorded.
• DR-0032 and DR-0033 moved to docs(governance): DR-0032 and DR-0033, revised against DR-0036 #8519 (draft), parked pending Minor releases sometimes break older buyers, and our versioning rules disagree about whether that's allowed #8501. They took the LADON.md and constitution rules that enforce DR-0033 with them, so this PR no longer touches LADON.md.

CI is green. Ready for a human merge.