Zanie Blue
782ab88aca
This fits with our other support policies, it's not a part of the uv versioning policy. Co-authored-by: Claude <noreply@anthropic.com>
40 lines
1.7 KiB
Markdown
40 lines
1.7 KiB
Markdown
# Versioning
|
|
|
|
uv is widely used in production and is stable software.
|
|
|
|
uv uses a custom versioning scheme in which the minor version number is bumped for breaking changes,
|
|
and the patch version number is bumped for bug fixes, enhancements, and other non-breaking changes.
|
|
|
|
The care we take in backwards-incompatible changes is proportional to the expected real-world
|
|
impact, not a function of arbitrary version numbering policies. We value the ability to iterate on
|
|
new features quickly and gather changes that _could_ be breaking into clearly marked releases.
|
|
|
|
uv's changelog can be [viewed on GitHub](https://github.com/astral-sh/uv/blob/main/CHANGELOG.md).
|
|
|
|
## Crate versioning
|
|
|
|
uv's crates are published to [crates.io](https://crates.io). The following crates follow the normal
|
|
uv versioning policy:
|
|
|
|
- `uv`
|
|
- `uv-build`
|
|
- `uv-version`
|
|
|
|
The `uv` and `uv-build` crates are versioned by the binary command-line interface. The Rust
|
|
interface of these crates does not follow semantic versioning.
|
|
|
|
The remainder of uv's crates provide **no stability guarantees**. The Rust interface is considered
|
|
internal and unstable. Consequently, they are versioned as `0.0.x`. The patch version is incremented
|
|
on every uv release, regardless of changes to the crate.
|
|
|
|
## Cache versioning
|
|
|
|
Cache versions are considered internal to uv, and so may be changed in a minor or patch release. See
|
|
[Cache versioning](../../concepts/cache.md#cache-versioning) for more.
|
|
|
|
## Lockfile versioning
|
|
|
|
The `uv.lock` schema version is considered part of the public API, and so will only be incremented
|
|
in a minor release as a breaking change. See
|
|
[Lockfile versioning](../../concepts/resolution.md#lockfile-versioning) for more.
|