You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Package the AdCP 3.3 schema bundle (3.3.0-beta.0) #1560
The protocol repo's Generate Python SDK check on the AdCP 3.3.0-beta.0 Version Packages PR (adcontextprotocol/adcp#7897) fails here:
sdk/MANIFEST.in does not package the pinned SDK schema recursive-include src/adcp/_schemas/3.2 *.json
SDK bundle key '3.2'; candidate bundle key '3.3.0-beta.0'
The SDK pins the 3.2 bundle key. Generation against the 3.3 line needs a 3.3.0-beta.0 bundle key (full version for prereleases), plus the matching MANIFEST.in include.
That check isn't required on the protocol repo, so it doesn't block the beta. It does mean the Python SDK isn't validated against the 3.3 bundle until this is fixed.
Fixed on next, the draft-spec / pre-release line (RELEASING.md routes 3.3 work there), and released in 10.0.0-beta.5 (v10.0.0-beta.5, pre-release).
A prerelease keeps its full-version bundle key, so the pin is 3.3.0-beta.3 and resolve_bundle_key("3.3.0-beta.3") is 3.3.0-beta.3. pyproject.toml package data and MANIFEST.in include _schemas/3.3.0-beta.3, _compliance/3.3.0-beta.3 and schemas/cache/3.3.0-beta.3 (the signed, cosign-verified bundle: sha256 ba61919c…). This landed with the beta.3 adoption (feat(protocol)!: adopt the signed AdCP 3.3.0-beta.3 bundle #1754); beta.2 is pruned from distributions. main (9.x, AdCP 3.2) deliberately keeps the 3.2 key and does not package 3.3.
The CI note: the protocol repo's "Generate Python SDK" job now checks out next, not main, so the 3.2 pin that produced sdk/MANIFEST.in does not package the pinned SDK schema … is not the one it sees.
I reproduced that job locally against next with the published 3.3.0-beta.3.tgz served from a local host (bundle-key step: both keys 3.3.0-beta.3, no edit needed; make regenerate-schemas; make validate-generated up to date; tests/test_code_generation.py tests/test_schemas_version_pin.py: 135 passed). The real job builds from a protocol PR bundle, so I could not run that exact input.
Install the tag now with pip install "adcp @ git+https://github.com/adcontextprotocol/adcp-client-python@v10.0.0-beta.5" (verified in a clean venv: package 10.0.0b5, spec 3.3.0-beta.3). The PyPI upload (pip install --pre "adcp==10.0.0b5") is waiting on the release-publish environment approval.
Activity
bokelley commentedon Oct 31, 2026
Fixed on
next, the draft-spec / pre-release line (RELEASING.md routes 3.3 work there), and released in10.0.0-beta.5(v10.0.0-beta.5, pre-release).3.3.0-beta.3andresolve_bundle_key("3.3.0-beta.3")is3.3.0-beta.3.pyproject.tomlpackage data andMANIFEST.ininclude_schemas/3.3.0-beta.3,_compliance/3.3.0-beta.3andschemas/cache/3.3.0-beta.3(the signed, cosign-verified bundle: sha256ba61919c…). This landed with the beta.3 adoption (feat(protocol)!: adopt the signed AdCP 3.3.0-beta.3 bundle #1754); beta.2 is pruned from distributions.main(9.x, AdCP 3.2) deliberately keeps the3.2key and does not package 3.3.next, notmain, so the3.2pin that producedsdk/MANIFEST.in does not package the pinned SDK schema …is not the one it sees.nextwith the published3.3.0-beta.3.tgzserved from a local host (bundle-key step: both keys3.3.0-beta.3, no edit needed;make regenerate-schemas;make validate-generatedup to date;tests/test_code_generation.py tests/test_schemas_version_pin.py: 135 passed). The real job builds from a protocol PR bundle, so I could not run that exact input.Install the tag now with
pip install "adcp @ git+https://github.com/adcontextprotocol/adcp-client-python@v10.0.0-beta.5"(verified in a clean venv: package10.0.0b5, spec3.3.0-beta.3). The PyPI upload (pip install --pre "adcp==10.0.0b5") is waiting on therelease-publishenvironment approval.🤖 Generated with Claude Code