With Lance now powering production workloads across multiple organizations, the core storage layer has matured and become more stable over time. As part of our ongoing evolution of the project—and following recent updates in Lance community governance — we’re excited to announce that the core Rust SDK and the Python and Java binding SDKs are graduating to version 1.0.0, alongside a new, community-driven release strategy.
This post outlines what 1.0.0 represents, how releases will work moving forward, and how this affects related components such as the Lance file format, table format, and namespace specifications.
Why 1.0.0?
Arriving at version 1.0.0 for the Lance SDK signals that the system is widely used and deployed in production, with real evidence for its robustness. Additionally, the community has aligned on a new release governance model, ensuring transparency, predictability, and shared ownership.
This moment marks the transition from an early, “rapid iteration” approach to a more deliberate, formally-versioned evolution of the SDK.
Adopting Semantic Versioning (SemVer)
Starting with 1.0.0, Lance SDK releases will be based on semantic versioning:
- MAJOR version — breaking API changes
- MINOR version — new, backward-compatible features
- PATCH version — bug fixes against a specific major/minor release
The SemVer approach to releases is designed to improve clarity and empower both individual contributors and downstream projects that depend on Lance.
The updated release process is designed to:
- Enable community voting on stable release candidates before an official release.
- Support patch releases for the latest stable branch for critical fixes identified by community maintainers.
For more details, see Lance release process in the documentation.
What about Lance 2.1?
A few months ago, we wrote on this blog about updates to Lance 2.0 / 2.1. These refer to the file format version of Lance, not the SDK.
Below, we further clarify the difference between the file format and SDK version numbers.
Lance File Format (currently 2.1): This version tracks on-disk binary compatibility, similar to Parquet format versions. It is not tied to the SDK version. It evolves independently and at a slower cadence. See Lance File Format Versioning for more.
Lance Table Format: The table format maintains full backward compatibility and avoids the use of linear version numbers, instead relying on feature flags for new table-level features. This ensures that we never break existing data or metadata. See Lance Table Format Versioning for details.
Lance Namespace Spec: Each namespace operation is versioned individually. It follows an upgrade strategy similar to the APIs in the Iceberg REST Catalog spec. It also evolves independently of the SDK. See Lance Namespace Spec Versioning for more.
In summary, only the SDK is adopting SemVer 1.0.0. The file format, table format, and namespace spec continue to follow their own established versioning strategies.
Cadence of Breaking Changes
Moving forward, breaking changes to the SDKs will be indicated by a major version bump (e.g., 2.0.0, 3.0.0).
Importantly:
- Breaking changes will NOT invalidate or require rewriting existing Lance data.
- Only SDK-level (user-facing) APIs may change.
- Migration steps, if any, will remain straightforward, and published in the Migration Guide .
This cadence allows the SDK to evolve rapidly to cater to users’ needs while ensuring long-term stability of data on disk.
Closing Thoughts
The release of Lance SDK 1.0.0 is more than just a milestone marker — it signifies the maturity of the format, the strength of the community, and a commitment to sustainable, collaborative evolution across the entire Lance ecosystem.
If you rely on Lance in production or are considering adopting it, this new release model ensures you’ll benefit from both reliability and innovation, with clear guarantees at every layer of the stack.
