Versioning

For contributors and integrators who want to understand how OSBP versions its public releases, and why the plan includes one deliberate breaking release before v1.0.

OSBP (Open Service Booking Protocol) is a narrow domain protocol that lets an AI agent book a service appointment on a user’s behalf, under explicit, scoped permission. It rides on the Model Context Protocol (MCP) for transport: MCP carries the bytes, OSBP defines what the booking tool calls mean and the guardrails around them (a user-approved BookingMandate, local idempotency, an audit trail, and fail-closed behavior on anything unknown or unauthorized). The booking platform remains the system of record.

The contract OSBP exposes is a small set of tools plus the shapes they exchange (BookingMandate, Slot, Booking, Policy, Problem, and so on). External parties integrate against that contract, and the durability of that contract is the whole game: every breaking change to it forces every integrator to re-integrate.

The short version

• v0.1.0 (the first public release line) is a deliberately formative proof, not a stable contract. Its first publication was June 15, 2026; the launch-ready public revision is dated 2026-07-08.
• The plan is to reach a durable v1.0 with the fewest possible breaking releases: ideally exactly one more.
• v0.2.0 is strictly additive (nothing renamed or removed): hosted/remote transport, authentication, OSBP contract version negotiation, broader agent-host reach, a next-availability read, and challenge.* added alongside deprecated verification.* aliases.
• v0.3.0 is the single planned breaking release. It locks the booking-lifecycle and correctness contract (cancel, change, error model, mandate evolution, contention control), removes the deprecated verification.* aliases, and ships with a migration guide and conformance tests, all at once.
• Everything after v0.3.0 is additive again, until v1.0 freezes a contract that has already proven itself.

Where OSBP is today (v0.1.0)

v0.1.0 is the inaugural public release line. Its first publication was June 15, 2026, and the launch-ready public revision is dated 2026-07-08. It is intentionally labeled 0.1.0, not 1.0.0: the version string is a promise, and 0.x means “usable proof, formative contract, breaking changes expected.” 1.0 is reserved for when the contract has stabilized in practice.

v0.1.0 ships a read lane (service.describe, availability.find, policy.explain, booking.status) and a create-only mutate lane (booking.create), plus verification (verification.send, verification.verify) and handoff.request. It carries the BookingMandate authority object, local idempotency, an audit envelope, and fail-closed validation. The public repository includes the protocol core, the local stdio MCP server package, a credential-free synthetic reference backend, a conformance kit, an adapter starter, and the Openings adapter/integration kit for Openings’ booking platform. It works and it is real, but it has not yet been pressure-tested across the booking world it intends to serve. See the specification for the full surface.

Additive versus breaking

Every future change falls into one of two categories.

• Additive change introduces new optional capability without altering what existing integrators already depend on: a new optional read tool, a new optional field, a new name added beside an old one that still works. Under OSBP’s robustness rules (must-ignore-unknown-fields on read, reserved extension namespaces), an integrator who does nothing keeps working. Additive releases cost integrators nothing, so OSBP can ship many of them.
• Breaking change alters or removes something integrators depend on, such that they must change their code to keep working: a renamed-and-removed operation, a changed object shape, a new required field on a mutation. Breaking releases force re-integration, and they are the churn that erodes trust. A rename is breaking only when the old name stops working; adding the new name while keeping the old as a deprecated alias is additive (this is how v0.2.0 introduces challenge.*).

OSBP’s contract is explicitly designed to keep most evolution additive: must-ignore-unknown-on-read, must-understand-and-fail-closed on mutation payloads, stable unknown member enums, and reserved extension namespaces. The catch is that this machinery has to be present in the contract before it can protect anyone, and v0.1.0 does not yet carry all of it.

Why any breaking releases at all

If v0.1.0 is the contract, why not freeze it now and only ever add? Because:

1. v0.1.0 encodes single-platform, single-vertical assumptions that will prove wrong. Cross-vertical research (healthcare, restaurants, fitness, home and auto services, aggregators) shows the real interaction surface is wider, and some v0.1.0 shapes carry personal-services assumptions. A formative phase exists precisely so they can be corrected.
2. Some required changes are breaking by nature. The current error object cannot tell an agent what to do next; cancel, change, and the signal lane all need a next_action directive. The verification step is renamed to challenge (step-up authentication, RFC 9470), and retiring the old name is a removal. The BookingMandate needs a type discriminator. Contention control needs an optimistic-concurrency token enforced as must-understand. Each is a shape change consumers must validate.
3. The durability machinery itself must be installed once, and installing it is the breaking step. The reserved seams for cancel, change, signal, and contention are what make later evolution additive. Putting them in is a one-time contract change, after which additive evolution is safe.
4. Now is the cheapest this will ever be. The integrator base is small and has been explicitly warned by the 0.x label. Doing these corrections after a 1.0 stability promise would be either forbidden or expensive and trust-damaging.
5. Zero breaking releases produces a worse contract, not a kinder one. Forbidding all breaking changes would force cancel, change, and contention to be bolted on around the v0.1.0 shapes, arriving at 1.0 full of compatibility scars. One clean breaking release yields a more durable contract than a dozen additive workarounds.

The conclusion: minimize the number of breaking releases (target: one more), batch every breaking change into it, do it while the contract is still formative and adoption is small, and use it to install the seams so everything afterward is additive.

The cadence

Release	Nature	Headline contents	Breaks integrators?
v0.1.0 (launch-ready revision 2026-07-08)	Formative proof	Read + create, mandate, idempotency, audit, fail-closed; protocol core, credential-free synthetic reference backend, conformance kit, adapter starter, and Openings adapter/integration kit	n/a (first release)
v0.2.0 “Remote reach” (planned)	Additive (nothing removed)	Hosted MCP over HTTPS, OAuth auth, verifiable agent identity, OSBP contract version negotiation, broader agent-host reach, next-availability read, challenge.* added with deprecated verification.* aliases	No
v0.3.0 “Lifecycle + correctness lock” (planned)	Breaking (the one)	cancel + change, the next_action/Problem/mandate-evolution contract, contention control, removal of the verification.* aliases, reservation of the evidence-backed seams; ships with a migration guide and conformance tests	Yes, once
Later 0.x	Additive	Signal lane, convenience reads, more verticals/profiles, payment-mandate composition reference, all behind reserved seams	No
v1.0 “Freeze”	Stabilization	Freeze a contract already proven across hosts and verticals	No (freeze)

v0.2.0, remote reach (additive)

Stand OSBP up as a hosted, authenticated, remotely reachable server, and get it onto more agent surfaces. This is transport, deployment, and authentication, plus additive read capability. It does not change or remove anything existing integrators depend on, so it breaks no one, and it produces real multi-host usage, which is the best possible input for getting the v0.3.0 contract right. Two refinements move the contract forward while keeping v0.2.0 strictly additive:

• Rename via aliases, not a break. Add challenge.send / challenge.submit as the going-forward names, and keep verification.send / verification.verify as deprecated aliases that still work. Nothing is removed, so nothing breaks; the aliases are removed in v0.3.0.
• Ship OSBP contract version negotiation. A domain-level version and capability handshake, distinct from the MCP protocol version, so a client can discover and pin the OSBP booking-contract version it was built against, and migrate on its own schedule.

v0.3.0, lifecycle and correctness lock (the one breaking release)

This is where the contract becomes durable. It batches every remaining breaking change:

• Cancel and change (destructive lifecycle operations), with the evolved BookingMandate (type discriminator, per-action scoping), the challenge step-up model, the Problem error model with next_action, and outcome_kind, all carrying stable unknown members and fail-closed-on-mutation rules.
• Contention control: an enforced optimistic-concurrency token on mutations and, where the platform supports it, short-lived holds, so two agents cannot silently double-book and a deposit cannot commit against a lost slot.
• Remove the deprecated verification.* aliases introduced in v0.2.0.
• Reserve the evidence-backed seams: only the ones the lifecycle, correctness, and signal work actually require. Speculative future-vertical shapes are not pre-reserved; the generic extensibility rules let those be added additively later, when a real driver appears. v0.3.0 is a lock, not a junk drawer.

Everything breaking goes here, together, once, and it ships with a migration guide (every break, with before/after and the alias-removal list) and conformance tests an integrator can run.

Later 0.x, additive only

With the seams installed, the rest of the backlog ships additively: the signal lane (advisory signals such as “running late”), convenience reads, additional platform adapters and verticals, and the payment-mandate composition reference. None of these require breaking the contract.

v1.0, freeze

Declare stability once the contract has run in production across multiple hosts and at least one vertical beyond personal services, and the reserved seams have absorbed real feature growth without a break. Because the seams exist, even post-1.0 growth stays additive.

Support and deprecation policy

While OSBP is pre-1.0 the policy is modest but explicit:

• Only the latest 0.x is supported at a time.
• Additive changes apply without notice; they break nothing.
• A deprecated surface (such as the verification.* aliases) is marked deprecated when its replacement ships, and removed no sooner than the next breaking release, with at least 90 days of advance notice.
• After v1.0, breaking changes follow semantic versioning with a longer, separately defined support window.

This is what makes the alias-then-remove pattern honest: integrators get a defined runway, not a surprise removal. The public-facing summary of this rule lives in Governance.

The standing rule

Default to additive. A breaking change requires explicit justification and must be batched into the next planned breaking release, never dribbled across several. Reserve seams aggressively (but only evidence-backed ones) so that future features stay additive. The target is that v0.3.0 is the last breaking release before v1.0. If a second breaking release becomes unavoidable, that is a signal the contract was locked too early, and it should be discussed, not absorbed quietly.

See also the roadmap for the public-facing direction, and the specification for the current contract.