Skip to content

docs: add a playbook for REST API version upgrades - #834

Open
nieblara wants to merge 2 commits into
mainfrom
cursor/api-version-upgrade-playbook-cf0d
Open

nieblara wants to merge 2 commits into
mainfrom
cursor/api-version-upgrade-playbook-cf0d

Conversation

@nieblara

@nieblara nieblara commented Sep 29, 2026 •

Copy link
Copy Markdown
Contributor

Requirements

  • I have added test coverage for new or changed functionality
  • I have followed the repository's pull request submission guidelines
  • I have validated my changes against all supported platform versions

This is documentation. The platform checkbox stays open because the playbook does not change runtime behavior.

Related issues

REL-16083 and #832, the api-client-go v24 / LD-API-Version: 20240415 upgrade this playbook came out of.

Describe the solution you've provided

Adds docs/playbooks/rest-api-version-upgrades.md and a pointer in CONTRIBUTING.md.

The playbook is the checklist for any future api-client-go bump or LD-API-Version change. It avoids facts that go stale after one upgrade. Instead of listing commands, versions, or known-bad operations, it gives the lookups that produce them:

  • rg searches for callers of the typed client and the resources client.
  • A lookup of the LD-API-Version a given api-client-go major sends by default.
  • A jq query over ld-openapi.json for operations that require beta but lack a (beta) tag, so the generator sets IsBeta: false for them.
  • The spec's own version changelog for what changes for older tokens.

It also covers the patch-body regression, which tests have to fail if the pin is wrong, and the live checks go test does not perform.

Each command in the playbook was run on main and on the PR 832 head (5af62e9). The spec query returns the five agent-graph operations on both, which is the open issue in PR 832.

Describe alternatives you've considered

Keeping the checklist only in the PR 832 description. A playbook in the repo is what the next upgrade can follow without re-deriving the two-client layout.

Additional context

No live API calls were made.


Note

Overview
Adds contributor guidance for api-client-go bumps and LD-API-Version changes, which unit tests alone do not fully validate.

CONTRIBUTING.md now links to a new playbook and states that PRs touching the client or version header should follow it before marking validation complete.

docs/playbooks/rest-api-version-upgrades.md documents a repeatable process: the typed client (internal/client.New) vs resources client (MakeRequest / generated commands), pre-edit lookups (rg, jq on ld-openapi.json for beta-only operations), a code checklist, required unit tests (headers, generator IsBeta, PATCH "value": false), and manual live checks (login, list/get commands, dev-server sync). It also lists what to document in the PR (target version, breaking model changes, older-token behavior).

Reviewed by Cursor Bugbot for commit e2817df. Bugbot is set up for automated code reviews on this repo. Configure here.

cursoragent and others added 2 commits September 29, 2026 21:49
Record how to validate an api-client-go bump and an LD-API-Version pin, including the second HTTP client and generated commands whose beta flag is not in the OpenAPI tag.

Co-authored-by: Ramon Niebla <nieblara@users.noreply.github.com>
Replace PR-specific history, hard-coded version facts, and command lists with lookups that stay correct: a spec query for beta-only operations, searches for each client's callers, and the client's own default header.

Co-authored-by: Ramon Niebla <nieblara@users.noreply.github.com>
@nieblara
nieblara marked this pull request as ready for review September 30, 2026 02:31
@nieblara
nieblara requested a review from a team as a code owner September 30, 2026 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants