adcp 10.0.0b4/b5 still install with adcp-reporting-storage 0.2.0b0 and fail every reporting turn; the docs say that pair is refused at startup #1837

#1763's pair still installs and fails every reporting turn. adcp-reporting-storage==0.2.0b0 requires adcp>=9.0.0,<11. adcp 10.0.0b4 and 10.0.0b5 are on PyPI, unyanked, and they predate the storage-contract startup check (#1789). So this resolves cleanly:

pip install 'adcp==10.0.0b5' 'adcp-reporting-storage[pg]==0.2.0b0'

We checked it in a fresh environment built from the published wheels against PostgreSQL 15. Every reporting turn fails with UndefinedColumn: column "offering_id" does not exist, logged as "worker component configuration failed". This is the original #1763 failure, not a startup refusal. (10.0.0b6 was never published.)

The refusal works where it exists. adcp==10.0.0b8 with 0.2.0b0 refuses before touching the schema, with a clear message naming both versions. adcp==10.0.0b5 with 0.2.0b1 works.

Docs that overstate the guard

• docs/reporting-ledger-migration.md:291 (at adcp-reporting-storage-v0.2.0-beta.1): "From 0.2.0b1 the pair is refused at startup instead". That is only true for adcp 10.0.0b7+.
• packages/adcp-reporting-storage/README.md:62: "if one is forced, building a PostgreSQL store refuses at startup, naming both versions". With adcp ≤ 10.0.0b3 and storage 0.2.0b1 forced, importing ledger/pg.py raises ImportError (_CONFIGURATION_COLUMNS, lines 95–97) before require_adcp_contract() (line 263) runs. This is cosmetic, because the >=10.0.0b4 floor stops pip from resolving that pair, but the sentence isn't accurate.

Options

1. Yank adcp 10.0.0b4 and 10.0.0b5 on PyPI. A 10.0 pre-release resolve then lands on b7+, which refuses the old storage loudly. Anyone pinned to b4/b5 keeps working, because yanked files still install when pinned exactly.
2. Yank adcp-reporting-storage 0.2.0b0. It is the only storage release that allows adcp 10.0.0b4+ without implementing contract 2.
3. Docs only. Say the refusal needs adcp ≥ 10.0.0b7, and list the b4/b5 + 0.2.0b0 pair as broken in the README compatibility table.

Whichever is chosen, fix the two sentences above.

Found during a post-release review of the #1787 migration. That review also confirmed that an in-place upgrade of a 0.1.0b4 or 0.2.0b0 ledger to 0.2.0b1 preserves every row and leaves a catalog identical to a fresh 0.2.0b1 schema.

🤖 Generated with Claude Code