The reliable way to version a published API here is a path segment: build your breaking change as a new endpoint at /v2/items while /v1/items keeps running exactly as it always has. Both are genuinely separate endpoints with their own graphs, so callers on the old version are never affected by work on the new one, and you can retire /v1 on your own timeline (see "Rate limiting, CORS, and authenticating incoming requests" for the Deprecation and Sunset settings that help with that).
Setting it up
When creating an endpoint, just give it a path starting with a version segment, /v1/items, /v1/items/:id, and so on. The endpoint creation form shows a reminder of this convention if your path doesn't already start with one, it's a suggestion, not a requirement, plenty of APIs never need more than one version.
What this does for your docs
Your generated OpenAPI document (at /openapi.json) automatically groups endpoints by their leading version segment as a tag, so /v1/... and /v2/... endpoints show up clearly separated in the hosted docs page, with no need to tag every endpoint by hand. An endpoint you've already given explicit tags of its own keeps those instead.
What the free form "version" field does instead
An endpoint's Settings panel also has a separate, informational version field, it adds an X-API-Version response header and appears in the OpenAPI document's own version number, useful as a label, but it has no effect on routing. The path segment approach above is what actually determines which graph runs.