uv 0.13.0 于 UTC 时间 10 月 9 日、韩国时间 10 月 10 日发布。在未请求或未固定版本时下载的默认稳定版 Python 从 3.14 改为 3.15。
已经安装的兼容 Python 仍会继续使用。例如，uv venv 仍可使用已安装的 Python 3.14。
如果没有安装合适的解释器且启用了自动下载，uv venv、uvx python 等命令现在可能会下载 Python 3.15。发布说明指出，像 uv venv --python 3.14 这样明确请求 3.14，或在项目中用 uv python pin 3.14 记录版本，即可避免这一行为。
Python 版本请求与自动下载
根据 uv 的 Python 版本文档，--python 选项用于请求所需的版本，uv python pin 会在当前目录创建 .python-version 文件。uv 会在工作目录及其上级目录中查找该文件，并把它作为默认的版本请求。
自动下载可以通过 python-downloads 设置关闭，也可以向任何 uv 命令传入 --no-python-downloads 标志来关闭。
固定 uv 可执行文件的版本与固定 Python 版本是两个独立的决定。工具版本决定采用哪种选择行为，Python 请求决定任务使用哪个解释器。
更严格的约束文件处理
以前，从 requirements 文件通过 -c 引入的约束文件中的 --require-hashes 会被忽略。现在 uv 遵循这一指令，要求安装中的所有要求都带哈希，因此只要有条目缺少哈希，以前能成功的安装就可能失败。
只要指令存在，就无法关闭这一行为。要么补上缺失的哈希，要么在并非有意进行哈希检查时，从引入的约束文件中删除该指令。
引入的约束文件中的 editable（-e）要求也不再被静默忽略，而是报错拒绝，与 pip 的行为一致。这类条目应移到通过 -r 传入的 requirements 文件，或用 --editable 直接传入。
新 CI 中暴露的解释器差异
开发机可能因为复用已安装的 3.14 而成功，干净的 CI 环境却可能下载 3.15。即使 uv 版本相同，结果也会因已安装的 Python 而不同。
在测试记录中写下实际选中的解释器版本，就能直接比较两个环境的差别。
新失败指向什么
哈希错误未必是 resolver 回退，而可能是以前被忽略的完整性策略第一次被执行。需要检查的不只是顶层 requirements 文件，而是通过 -c 连接的所有文件。
移动 editable 条目时，约束和安装请求的作用不同，因此移动后实际安装的内容可能发生变化。
注意事项：两项变化同时出现时
如果解释器选择和约束文件处理在同一次升级中一起变化，失败的原因就有两种可能，即使成功也可能掩盖环境差异。本文没有亲自运行 uv 安装、环境创建或依赖解析。
10 月 10 日这一期采用的是韩国日期，发布来源的日期是 10 月 9 日。
uv 0.13.0 把未固定的 Python 下载改为 3.15，并强制执行引入约束文件中的哈希和 editable 规则，因此只有把解释器选择和约束文件处理分开看，升级失败的原因才会清楚。