uv/docs/reference/versioning.md
Charlie Marsh 2651aee33f
Enforce lockfile schema versions (#8509)
## Summary

Historically, we haven't enforced schema versions. This PR adds a
versioning policy such that, if a uv version writes schema v2, then...

- It will always reject lockfiles with schema v3 or later.
- It _may_ reject lockfiles with schema v1, but can also choose to read
them, if possible.

(For example, the change we proposed to rename `dev-dependencies` to
`dependency-groups` would've been backwards-compatible: newer versions
of uv could still read lockfiles that used the `dev-dependencies` field
name, but older versions should reject lockfiles that use the
`dependency-groups` field name.)

Closes https://github.com/astral-sh/uv/issues/8465.
2024-10-24 12:23:56 -04:00

20 lines
904 B
Markdown

# Versioning
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.
uv does not yet have a stable API; once uv's API is stable (v1.0.0), the versioning scheme will
adhere to [Semantic Versioning](https://semver.org/).
uv's changelog can be [viewed on GitHub](https://github.com/astral-sh/uv/blob/main/CHANGELOG.md).
## 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.