What is the difference between API versioning and application versioning?

In production I track several independent identities: immutable artifact or image digest, application release, source commit, configuration revision, database migration state, event schema, and supported HTTP API versions. Coupling them would create a new public API version for every deployment and teach clients nothing useful. During rolling releases, old and new application builds may serve the same API version simultaneously, so shared data, error behavior, and response semantics remain compatible. A single application build may also serve v1 and v2 through thin adapters over shared use cases. API-version usage telemetry, ownership, support policy, deprecation signals, migration guidance, and removal criteria govern the client lifecycle; release telemetry and rollback history govern the application lifecycle. Security fixes may produce a new application release across every supported API version without changing those contracts. Conversely, introducing API v2 is not complete merely because routing works: documentation, SDKs, authorization, monitoring, consumer migration, and the retirement plan must exist. This separation gives operations exact provenance while clients receive stable, meaningful compatibility boundaries.