ci: use release-please manifest prerelease config

[bokelley]

Summary

• Switch Release Please to manifest mode so release-please-config.json is honored.
• Keep the existing Python release strategy through manifest config, including versioning: prerelease.
• Document beta-line behavior so beta releases increment beta.N instead of bumping the base minor version.

Why

The workflow passed release-type: python directly to the action. In that mode, Release Please does not use the advanced manifest configuration, so the beta prerelease strategy was not reliably driving release PR versions.

Validation

• python3 -c 'import json; json.load(open("release-please-config.json")); json.load(open(".release-please-manifest.json"))'
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/release-please.yml")'
• git diff --check
• npx release-please debug-config --repo-url adcontextprotocol/adcp-client-python --target-branch main --local --local-path . confirmed manifest config parses with versioning: prerelease and current version 6.3.0-beta.4.

[aao-ipr-bot]

LGTM. Follow-ups noted below. Manifest mode is the right shape — the existing release-please-config.json already declares versioning: prerelease + prerelease-type: beta, and release-type: python as an action input was bypassing it entirely.

Things I checked

• release-please-action@v5 invocation: with config-file + manifest-file and no release-type, the action takes the Manifest.fromManifest path and honors the config file. Setting release-type would have flipped it back to Manifest.fromConfig, which ignores the config file — that was the bug.
• Downstream plumbing: steps.release.outputs.prs_created and the release-please--branches--main branch name are populated by release-please core, not the input mode. The Normalize release PR pyproject prerelease version step still gates and runs identically.
• Bump math at 6.3.0-beta.4: feat: and fix: both route through bumpPrerelease("beta.4") → 6.3.0-beta.5. Matches the docs.
• release-please-config.json and .release-please-manifest.json are syntactically valid and reachable (PR's debug-config evidence).

Follow-ups (non-blocking — file as issues)

• feat!: behavior is undocumented and contradicts the new copy. RELEASING.md:187 says "keep the base version fixed and increment only the beta counter." Tracing PrereleaseMajorVersionUpdate.bump for 6.3.0-beta.4 (minor=3, so the patch === 0 && minor === 0 guard is false): a breaking change exits the beta line and produces plain 7.0.0, dropping the prerelease label entirely. Narrow the claim to non-breaking commits and add a one-liner on the breaking-change escape hatch.
• No documented path from 6.3.0-beta.N to 6.3.0 stable. With versioning: prerelease the counter only increments. Graduation needs a manual Release-As: 6.3.0 footer (or a manifest edit). This will be the next support question — worth a 3-line "Graduating a beta" subsection.
• bump-minor-pre-major: true / bump-patch-for-minor-pre-major: false in release-please-config.json are inert at major=6. Pre-existing, not introduced here, but they imply they're shaping current behavior. Worth deleting in a sweep.
• Validation evidence covers parsing, not behavior. debug-config confirms the config is reachable; it doesn't simulate a feat: producing beta.5. A release-pr --dry-run against a synthetic commit would be stronger. Notable, because the very next release PR is the actual smoke test.

Minor nits (non-blocking)

1. PYPI_SETUP.md:78-80 attributes the behavior to "manifest-mode config" — the actual cause is versioning: prerelease. Implementation detail vs. user-facing rule. Optional reword.
2. PYPI_SETUP.md:77 still reads feat!: → major bump unconditionally. With the new bullet directly underneath, the two lines now have a subtle inconsistency on the beta line. Same fix as the RELEASING.md follow-up.

Approving on the strength of the mechanical change being correct and the downstream pipeline being undisturbed. The doc tightening can land in a follow-up.