warehouse-source-new-version

First diff the new version against the current default_version using the vendor changelog across auth, pagination, schemas, and webhooks. If it diverges, add the label to supported_versions, flip default_version, dispatch on SourceInputs.api_version in the request layer, and parameterize tests over both versions.

Skip adding it when no area the source reads differs from the current default version, since an extra label only adds maintenance cost. Close the task with per-area, changelog-cited evidence that the new label is indistinguishable from the default.

Each ExternalDataSource row pins one version in its api_version column, with NULL resolving to the source's default_version. A schema-level override in ExternalDataSchema.api_version wins over the source pin, and the sync pipeline resolves override, then pin, then default.

Add the old version to deprecated_versions with the vendor's sunset date and flip default_version to the newer version in the same PR. Only write a repinning migration when the vendor has announced a sunset date; advisory deprecations leave existing pins untouched.

Existing customer rows are pinned to specific versions, and silently moving them to another version is the failure mode the pinning framework prevents. Removing or altering an old version's request path is an explicit future decision, never part of a version-add PR.

Common pitfalls include version-to-header maps with .get() fallthroughs that silently send no version, ignoring the api_version parameter in get_schemas and validate_credentials, and reusing one resume-checkpoint field across incompatible pagination mechanisms. Tests must use per-version fixtures shaped from vendor docs.