Lance Data Storage Version

The `data_storage_version` property embedded in every Lance dataset's manifest, which independently governs the physical on-disk file-format stability contract — separate from the `lance`/`pylance` SDK's aggressively-bumped package version (the crate line reached v9.0.0 in July 2026, with the wider package tag at v10.0.0 stable / v11.0.0 beta by August 2026). A dataset written under a given `data_storage_version` (legacy `0.1`, stable `2.0`, `2.1`, or the current `2.2`) carries a backward-compatibility guarantee at that storage-version level, regardless of which SDK release wrote it or which SDK release later reads it.

Lance ships SDK major-version bumps far more aggressively than typical semver — tracking API surface changes, integration-layer growth (`lance-duckdb`, `lance-spark`, `lance-trino`, `lance-ray`), and in-memory representation work rather than physical storage breaks. Without a separate axis, every SDK major-version jump would read as a breaking-change signal, triggering unnecessary migration panic for teams with production datasets pinned to older readers. Splitting the two lets the SDK iterate fast — v7 to v11 in roughly a year — while giving operators exactly one field to check before an upgrade: the dataset's own `data_storage_version`, not the SDK's release tag.

Pre-upgrade compatibility checks before bumping the installed `lance` or `pylance` package in production, deciding whether a dataset needs an explicit rewrite onto a newer storage version versus a same-storage-version reader upgrade, and cross-tool interoperability where multiple SDK releases read the same physical dataset — e.g. a Spark job on one `lance` package version and a `lance-duckdb`-backed DuckDB query on another, both reading a table whose actual compatibility guarantee is fixed by its `data_storage_version`, not by either caller's SDK build.