Repository navigation
Description
The SDK needs a written rule for which branch carries which spec, so that draft-spec work doesn't ship in stable releases.
Problem
main releases the 9.x line on AdCP 3.2.x: src/adcp/ADCP_VERSION is 3.2.1, and release-please cuts 9.0.0-beta.N from it. main also carries experimental AdCP 3.3 identity code written to open drafts (#1502). #1514 and #1523 add more, aligned to adcontextprotocol/adcp#7894, #8162, #8168, #8169, and #8170. Those drafts change until 3.3 is ratified, so every draft change lands in a 3.2.x release, and the 9.0 line can't go stable while part of it tracks drafts.
The repo already has most of the model. release/7.x and release/8.x carry the older majors, and release-please runs on release/8.x. What's missing is a branch for draft-spec work and a rule for moving fixes between branches.
Proposal
Use the following branches:
| Branch | Carries | Releases |
|---|---|---|
main |
Work against the latest ratified AdCP version (3.2.x today) | The current major, through release-please |
release/N.x |
Fixes for an older major | Patch releases of that major |
next |
Work against draft specs, such as 3.3 agent identity and Web Bot Auth | Pre-releases only (for example, 10.0.0-alpha.N), from its own release-please configuration |
Move changes between branches with these rules:
- A fix lands on
mainfirst. A maintainer then backports it to eachrelease/N.xthat needs it. nexttakesmainregularly, through a merge or a forward-port PR, so it doesn't drift.- A change that only draft-spec work needs stays on
next. - When a spec version is ratified,
nextmerges intomain, and the next major releases frommain. - Labels such as
backport release/8.xandforward-port nextmark PRs that need a port. A backport action can open the port PRs.
Steps
- Create
nextfrommain, and add a release-please configuration for it. - Retarget fix(identity): align AdCP 3.3 agent identity with the final spec and the Go and TS SDKs #1514 and refactor(signing): RFC 9421 on http-message-signatures; align Web Bot Auth with adcp#7894 #1523 to
next. - Move feat(identity): add experimental AdCP 3.3 agent identity #1502 to
nextbefore 9.0.0-beta.4 (chore(main): release 9.0.0-beta.4 #1465) ships. It isn't in a release yet. - Write the rules in
RELEASING.md, or in a section ofCONTRIBUTING.md.
adcp-go and adcp-client have the same situation with their 3.3 identity work, tracked in adcontextprotocol/adcp#8118. If this model works here, they can adopt it too.
Activity
bokelley commentedon Oct 18, 2026
Implemented as proposed. The one difference:
nextis the renamednext/3.3branch, not a fresh branch frommain.next(done; it's not a protected branch)next/3.3→nextwith the branch-rename API, in two hops (next/3.3→next-rename-tmp→next), because git can't createrefs/heads/nextwhilerefs/heads/next/3.3exists. fix(identity): align AdCP 3.3 agent identity with the final spec and the Go and TS SDKs #1514 retargeted tonextautomatically; refactor(signing): RFC 9421 on http-message-signatures; align Web Bot Auth with adcp#7894 #1523 stays stacked on fix(identity): align AdCP 3.3 agent identity with the final spec and the Go and TS SDKs #1514's branch.next..github/workflows/release-please-next.yml: runs on push tonext, concurrency grouprelease-please-next,target-branch: next, and queuesrelease-publish.yml --ref next.release-please-config.next.json:versioning: prerelease,prerelease-type: alpha,prerelease: true, changelog inCHANGELOG.next.md..release-please-manifest.next.json: baseline9.0.0-beta.3. The adopting commit'sRelease-As: 10.0.0-alpha.0footer pins the first version; after that every release bumps the alpha number (10.0.0-alpha.1, ...). I verified this with a release-please dry run before pushing.--target-branch nextand accepts onlyrelease-please--branches--next--components--adcp→next.release-publish.yml(its file name stays, because Trusted Publishing is bound to it) builds frommainornextand waits for that branch's CI.10.0.0aNas a pre-release, sopip install adcpstays on 9.x.next("PR must target main"). PRs intomainornextnow pass the base check. Push checks remain main-only.chore(next): release 10.0.0-alpha.0, withpyproject.tomlnormalized to10.0.0a0.PRs into
main(not merged)main. It should merge before chore(main): release 9.0.0-beta.4 #1465 (9.0.0-beta.4); I commented there. One conflict, inclient.pyagainst feat(property-lists): unify resolution and validate seller inventory #1532'sproduct_property_policy, which the PR keeps. No later commit depends on feat(identity): add experimental AdCP 3.3 agent identity #1502. Its description has the-s ourssequence that keeps the identity code onnextafter the revert merges.nextrelease flow, the feat(identity): add experimental AdCP 3.3 agent identity #1502 procedure, and the ratification steps intoRELEASING.md. Thebackport release/8.xandforward-port nextlabels exist.Maintainer to-do, in order
-s ourssequence onnext(in revert: move experimental AdCP 3.3 identity from main to next #1534 andRELEASING.md).nextto therelease-publishenvironment's deployment branches. Today onlymain,release/7.x, andrelease/8.xare allowed, so anextpublish would be blocked.nextbefore merging chore(next): release 9.0.0 #1533, so10.0.0-alpha.0ships the aligned identity code.adcp-go took the other route the user chose for Go:
mainis the AdCP 3.3 pre-release line foradcp/v3(adcontextprotocol/adcp-go#578, which proposesadcp/v3.3.0-beta.0). Cross-SDK tracking: adcontextprotocol/adcp#8118.bokelley commentedon Oct 18, 2026
Follow-up: #1533, the
10.0.0-alpha.0release PR, had one failing test, theadcp.types.generated_pocalias's own v10 sunset check (REMOVED_IN_MAJOR = 10). #1536, intonext, removes the alias as planned (breaking: adopters runadcp migrate v3-to-v4 --apply). All checks pass and it's approved. Merge it intonextbefore #1533, then update #1533's branch.