airvzxf / airvzxf/voxora

check-cratesio-deps.py does not honor cargo's pre-release exclusion rule

オープン
#110 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
bug infrastructure
主要言語
Rust
スター
0
フォーク
1
平均マージ
11分
マージ済み PR(30日)
47

説明

## What

The Python semver matcher at `.github/scripts/check-cratesio-deps.py`
(introduced in #108) does not enforce cargo's pre-release exclusion
rule. Cargo excludes pre-release versions from a requirement
unless the requirement's lower bound names that pre-release
explicitly. The script's `key()` function inverts pre-release
ordering (releases sort BEFORE pre-releases of the same
`x.y.z`), and the caret/tilde/comparison branches use native
tuple comparison instead of routing through a corrected
comparator.

## Why it matters

For the current 0.4.2 → 0.4.3 cycle the rule is moot because no
pre-release has been published. If a future hotfix ever ships a
`voxora-traits-v0.4.3-rc1` for a dry-run, the guard would say
"✓ satisfied by voxora-traits 0.4.3-rc1" while `cargo publish`
would fail at dep-resolution time — the exact failure mode the
guard was added in #94/#108 to prevent.

## Reproduction (against the committed script)

```
$ printf "0.4.2\n0.4.3-rc1\n" | python3 .github/scripts/check-cratesio-deps.py '^0.4.2'
0.4.3-rc1 ← guard says satisfied

$ printf "0.4.2\n0.4.3\n0.4.3-rc1\n" | python3 .github/scripts/check-cratesio-deps.py '~0.4.2'
0.4.3-rc1 ← guard says satisfied
```

Versus cargo (verified with the `semver = "1.0.28"` crate that
`Cargo.lock:1` pins): `0.4.3-rc.1.matches("^0.4.2")` →
`false`. The pre-flight check would print "✓ voxora-traits
^0.4.2 satisfied by voxora-traits 0.4.3-rc.1 on crates.io" and
then `cargo publish` would fail at dep-resolution time.

## Recipe

Two coordinated changes in `.github/scripts/check-cratesio-deps.py`:

1. `key()` should return `(t[0], t[1], t[2], 0 if t[3] else 1, t[3])`
so pre-releases sort BEFORE the corresponding normal version
(semver 2.0 §11).
2. The caret / tilde / comparison branches should drop any
candidate whose `pv[3]` is non-empty unless the requirement's
lower bound names that pre-release exactly. Add a
`req_has_pre(req) -> bool` gate.

Then add a unit-test invocation to the `ci` job (or a
follow-up `.github/scripts/test-check-cratesio-deps.py`) that
exercises the pre-release rejection case.

## Acceptance

- `check-cratesio-deps.py '^0.4.2' 0.4.2 0.4.3-rc.1 0.4.3`
returns `0.4.3` (not `0.4.3-rc.1`).
- `check-cratesio-deps.py '>=0.4.0, <0.5.0' 0.4.2-rc.5` returns
nothing (pre-release excluded unless explicitly required).
- A regression test runs the script against a representative
pre-release candidate set on every CI build.

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。