Latest Results
Prefer stable releases for explicit pre-release requirements (#20302)
## Summary
Stacked on #19993.
The parent PR treats an explicit pre-release specifier as authorization
for matching pre-releases to participate in normal version ordering. For
example, when `c==1.0` and `c==2.0a1` are available, `c>=0.5a1` can
select the newer pre-release even though a compatible stable release
exists.
This changes the default and deprecated `explicit` policies to prefer
every compatible stable candidate before falling back to pre-releases.
Exact pre-release pins and ranges with no compatible stable candidate
still select pre-releases, and the ordering is consistent for direct and
transitive requirements regardless of discovery order.
Since explicit requirements no longer change candidate ordering, the
pre-release PubGrub proxy and its priority, pinning, and diagnostic
plumbing are unnecessary and are removed. The candidate universe remains
fixed per package identity: `allow` uses normal version ordering,
`disallow` excludes pre-releases, and the default policy performs stable
and then pre-release passes. Scenario expectations, user-facing
documentation, and the generated schema are updated to match.charlie/transitive-prerelease-pubgrub Latest Branches
-6%
charlie/transitive-prerelease-pubgrub -4%
charlie/stable-first-prereleases 0%
© 2026 CodSpeed Technology