chore(main): release 8.0.0-rc.1

[aao-ipr-bot]

🤖 I have created a release beep boop

8.0.0-rc.1 (2026-09-28)

docs

• release: note the 8.0.0 release candidate (#1238) (1a59739)

Features

• reporting: require positive installed artifact interop matrix (#1230) (4ceeffe)

---

This PR was generated with Release Please. See documentation.

[aao-secretariat]

Ladon does not review bot-authored PRs.

[bokelley]

Review — release PR, head 9aece6a0

Holding approval. The three-file delta itself is correct and I found no fault in it — but there is one CI failure on this head that I don't think a release PR should be approved over without an explanation. Detail at the bottom.

The version delta is right

file	value	form
.release-please-manifest.json	8.0.0-rc.1	SemVer (drives the v8.0.0-rc.1 tag and the changelog compare URL)
pyproject.toml	8.0.0rc1	PEP 440 canonical

Verified rather than eyeballed:

• Version("8.0.0-rc.1") == Version("8.0.0rc1") → True; both normalize to 8.0.0rc1.
• Ordering holds: 8.0.0b18 < 8.0.0rc1.
• is_prerelease stays True across the bump, so nothing that branches on prerelease status changes behaviour.
• The two-form split is intentional and matches the previous release (8.0.0-beta.18 / 8.0.0b18), so Release Please's manifest state stays consistent for the next run.

The 8.0.0-rc.1 → 8.0.0rc1 fixup in 9aece6a0 is a pipeline step, not a manual patch — scripts/normalize_pyproject_prerelease.py, invoked from release-please.yml:44 with --release-prs, and covered by tests/test_normalize_pyproject_prerelease.py. Good; future releases get it automatically.

Changelog is accurate, including what it omits

Three commits since the v8.0.0-beta.18 tag:

commit	in changelog?	correct?
feat(reporting) #1230	yes, under Features	✓
docs(release) #1238	yes, under docs	✓ (carries the Release-As: 8.0.0-rc.1 footer)
test(reporting) #1236	no	✓ — test isn't in changelog-sections and has no Release-As footer

I checked #1236's omission specifically rather than assuming it was a miss. The rc switch is genuine: Release-As: 8.0.0-rc.1 is in #1238's committed body, with prerelease: true / prerelease-type: rc configured.

No other version pin needs moving — extra-files is unset, there's no hardcoded __version__ in src/, and docs/reporting-release-notes.md already reads 8.0.0rc1 from #1238. Remaining 8.0.0b1x / beta.15 strings in docs are historical references to past releases, not pins.

I also confirmed the AdCP protocol gate is unaffected: get_supported_adcp_versions() reads the packaged ADCP_VERSION, not the package version, and still returns ('3.0', '3.1', '3.2-rc.7').

Nit, non-blocking: the entry renders as ### docs where 13 prior changelog entries used ### Documentation. docs isn't in changelog-sections, so it falls back to the raw type name; it's only present at all because of the Release-As footer. Adding a docs → Documentation mapping would fix the heading but would also start including every docs commit in future changelogs — not something to decide inside a release PR.

---

The blocker: one red check

B2.3 and hardening to installed B2.4 activation and restart — failed step "Run actual historical page one, activation, SIGKILL and cold continuations", exit 1. (39 success / 1 failure / 12 pending at time of writing.)

I don't think this is a flake. That job's recent record:

36422152433  failure    release-please--branches--main--components--adcp   <- this head
36417090922  success    docs/release-rc1
36408849794  success    main
36403214565  success    feat/reporting-full-installed-interop
36401145946  success    release-please--branches--main--components--adcp   <- prior release run
36400993968  success    main

Green everywhere recently, including on a previous release-please run of the same shape.

What I could and couldn't do:

• Logs aren't retrievable yet — gh run view --log-failed returns "run is still in progress" while the other 12 checks finish.
• I tried to reproduce locally against a real PostgreSQL. Blocked: test_reporting_rc6_rolling.py:94 asserts ADCP_PYTHON310, the installed Python 3.10 floor that CI provisions, so the run errors out before reaching the real assertions rather than reproducing the failure.

I'll note only that this is the installed-artifact compatibility job — the one that builds and installs the wheel — which makes it the job most plausibly sensitive to a version-string change. I'm flagging that as a hypothesis to check, not a diagnosis; I have no evidence for the cause.

Happy to read the logs and re-review the moment the run completes. If it turns out to be an infrastructure flake, say so and I'll approve on the delta, which I'm otherwise satisfied with.

[bokelley]

I pulled the completed job logs through the Actions jobs API while the workflow is still running. Both red jobs failed during isolated pip install stages with five repeated read_timeout errors from package downloads, before the installed-artifact assertions could run:

• B2.3→B2.4 activation/restart: b24-rc6-floor-install hit its 180-second deadline; stderr classification read_timeout on all five lines.
• PostgreSQL core: 2,000+ conformance tests completed, then wheel-base-install exited 1 after ~100 seconds with the same five read_timeout lines. The four reported setup errors share that fixture failure.

The errors are package-index reads, not version parsing or assertion failures. I will rerun the failed jobs as soon as Actions marks this workflow complete, and I will hold the merge until the current-head required checks are green.

[bokelley]

Independent confirmation: both reds are infrastructure

I pulled the same job logs myself rather than taking the summary on trust (gh api --allow-escape-sequences .../actions/jobs/<id>/logs — the escape-sequence flag is what made them retrievable while the run is still in progress). Your diagnosis holds, and the evidence is a bit stronger than stated.

The harness's own stderr classifier, identical in both jobs:

{"lines":10,
 "sha256":"bf595e96d6d0e613120f2247918eb2648e8c989eded513d0020157b79e5eebb4",
 "trace":[[1,["read_timeout"]],[2,["read_timeout"]],[3,["read_timeout"]],
          [4,["read_timeout"]],[5,["read_timeout"]]],
 "classification":"recognized"}

Two points that make this conclusive rather than suggestive:

1. The same stderr sha256 appears in both jobs — byte-identical failure output across two independent jobs on separate runners. That's a shared external cause, not anything reachable from a three-line version change.
2. Every failing label is an install stage, and there are four, not two:

job	stage	outcome
B2.4	hardening-b24-install-frozen-wheel	exit 1, ~101 s
B2.4	b24-rc6-floor-install	deadline, 180 s, exit=-15 cleanup=terminated
PG core	wheel-base-install	exit 1, ~100 s
PG core	sdist-base-install	exit 1, ~104 s

The AssertionErrors at test_reporting_notification_packaging.py:144 are the harness reporting "this install subprocess exited non-zero" — they are not version-parsing or installed-artifact assertions. Nothing got as far as evaluating artifact behaviour.

That also disposes of the hypothesis I flagged in my earlier review: I said the installed-artifact job was the one most plausibly sensitive to a version-string change and asked for it to be checked rather than assumed. It has been checked, and it isn't that — package-index reads timed out before any version was examined.

Verdict unchanged on the delta, which I'm satisfied with, and the two reds are not a code problem. I'll post a formal APPROVE once the reruns land green on this exact head. Ping me then — no re-review of the three files needed unless the head moves.

[bokelley]

APPROVE — exact head 9aece6a01aa5f1d7fbfb6bfa15ba961363ba7a4d, unchanged since my review, 53/53 checks green.

Basis:

• Version delta verified, not eyeballed — Version("8.0.0-rc.1") == Version("8.0.0rc1"); ordering 8.0.0b18 < 8.0.0rc1 holds; is_prerelease stays True; and the manifest/pyproject two-form split matches the previous release (8.0.0-beta.18 / 8.0.0b18), so Release Please's state stays consistent for the next run.
• PEP 440 normalization is a pipeline step, not a hand patch — scripts/normalize_pyproject_prerelease.py from release-please.yml:44, covered by its own test.
• Changelog accurate including its omission — test #1236 is correctly excluded (absent from changelog-sections, no Release-As footer); the rc switch is driven by the real Release-As: 8.0.0-rc.1 footer in #1238.
• No other version pin needs moving — extra-files unset, no hardcoded __version__, and the AdCP protocol gate reads the packaged ADCP_VERSION rather than the package version.
• Earlier reds resolved and independently diagnosed — I pulled the job logs myself and confirmed byte-identical read_timeout stderr (sha256 bf595e9…) across four install stages in two jobs; package-index reads, not code. Those jobs are green on rerun.

One non-blocking nit carried forward, not a merge condition: the entry renders as ### docs where 13 prior entries used ### Documentation, because docs isn't in changelog-sections and only appears here via the Release-As footer. Adding the mapping would also pull every future docs commit into the changelog, so it's a config decision for outside a release PR.

[aao-ipr-bot]

🤖 Created releases:

• v8.0.0-rc.1

🌻