Which Sanity apiVersion Pin Should Govern a Studio v3 Upgrade?

Sanity's Content Lake is versioned by date strings rather than semantic majors: a client declares an apiVersion such as 2023-05-03, and query and mutation behavior is gated on that pinned date. Separately, Sanity Studio v3 is a React application with its own Node.js and React runtime requirements, so a Studio major upgrade is a toolchain change rather than a routine dependency bump.

These two axes advance on different schedules. A single installed @sanity/client release can address many API versions, so compatibility is largely a function of the pinned date, not the package version. Community plugins declare peer dependency ranges against the Studio major, and those ranges often lag behind a release.

The unresolved decision is the pin policy. An older date preserves known behavior but forgoes later fixes and features; a recent or moving date lets behavior shift without any change in the repository. GROQ capabilities and content-lake semantics such as perspective and draft handling are tied to that date.

Which apiVersion should a team standardize on when moving to Studio v3? Does the Studio major constrain that choice at all, or are the two genuinely independent? When a plugin's peer range lags, what determines whether the pinned date can safely advance?