This email proposes upgrading the uv[1] package in EPEL10 from 0.5.31,
now in testing[2], to 0.6.0 or a later 0.6.x release. In upstream’s
words, “There have been 31 releases and 1135 pull requests since 0.5.0,
our last release with breaking changes. As before, we've accumulated
various changes that improve correctness and user experience, but could
break some workflows. This release contains those changes; many have
been marked as breaking out of an abundance of caution. We expect most
users to be able to upgrade without making changes.” The exact changes
are documented in the release notes for 0.6.0[3].
In addition to the bug fixes in 0.6.0 itself and the stabilization of
"uv publish," this update would allow EPEL10 users to continue to
benefit from very frequent bug-fix and feature releases in the 0.6.x
series. Given the narrow scope of the documented breaking changes, the
intended use of uv as a developer tool, and the rapid pace of upstream
bug-fix and feature releases, this seems a worthwhile trade-off.
If an incompatible upgrade is not approved, uv will remain at 0.5.31 in
EPEL10 indefinitely; no further upstream development in the 0.5.x series
is expected.
The purpose of this email is to document and explain the proposed
update, to begin the minimum one-week discussion period mandated by the
EPEL Incompatible Upgrades Policy, and to request that the update be
added to the agenda for an upcoming EPEL meeting.
Furthermore, I request that the EPEL steering committee consider whether
to approve a permanent exception for incompatible upgrades of the uv
package, similar to the one already approved in Fedora[4]. The basic
rationale is that uv is a key Python developer tool (versus a piece of
low-level “infrastructure,”) primarily used directly by human developers
rather than for building other packages and systems. Considering this,
holding the package at an older version would cause much more harm to
users – by allowing uv to fall behind the Python packaging ecosystem,
and by denying access to its rapidly-expanding features – than would be
caused by exposing users to occasional minor breaking changes.
Upstream’s track record in 0.x releases so far supports this; breaking
changes have always been narrow in scope and carefully considered. Even
given the high priority on long-term stability over “freshness” in EPEL,
I think this rationale still applies here.
If a permanent exception were approved, uv’s maintainers would of course
still be expected to do proper diligence before shipping a documented
breaking update in an EPEL branch, including reading and considering the
scope of potentially-breaking changes, impact-checking the new version
against any packages that might depend on uv, and refraining from
issuing an update if it seemed likely to cause significant disruption.
If a permanent exception is not approved, but a specific exception for
0.6.x is approved, then I expect to request additional specific
exceptions for future similar releases. At this phase in uv’s upstream
development, these formally-breaking releases seem to happen about every
three months.
– Ben Beasley (FAS: music)
[1] https://docs.astral.sh/uv
[2] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-9db52353f2
[3] https://github.com/astral-sh/uv/releases/tag/0.6.0
[4] https://pagure.io/fesco/issue/3262
--
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
