Files
RedBear-OS/local/scripts
vasilito 675c5e82fc
redbear-ci / check (push) Has been cancelled
fix: bump-release compares upstream CRATE versions, not git tags
The upgrade decision compared the newest upstream git TAG against $base,
which callers pass as the fork's Cargo.toml CRATE version. For several
Redox crates those namespaces are unrelated, so the comparison was
meaningless:

  relibc    git tags 0.5.0 / 0.6.0, but Cargo.toml AT tag 0.6.0 is 0.1.0,
            and our fork is 0.2.5 -> reported '0.2.5 -> 0.6.0 upgrade'
            when upstream master is 0.2.5, i.e. ALREADY CURRENT
  libredox  newest tag is v0.1.13, but upstream master is 0.1.19

Not cosmetic: upgrade-forks.sh consumes the result as --to=<ref> and does
'git reset --hard <ref>' before reapplying Red Bear commits as a net diff.
Acting on the relibc answer would have reset the fork onto an unrelated
lineage and reapplied our commits against it.

These forks are Cargo path deps with [patch.crates-io] and our label is
<upstream-version>+rb<branch>, so the CRATE version is the upstream
identity Cargo must satisfy -- compare crate-to-crate. Tag scanning
remains as the fallback for forks with no readable Cargo.toml.

Report after the fix:
  syscall  0.9.0  -> 0.9.1   upgrade   (tag 0.9.1 also exists)
  libredox 0.1.18 -> 0.1.19  upgrade   (master only; no matching tag)
  relibc   0.2.5              ok       (was a false positive)
  redoxfs / redox-scheme / userutils  ok

Known gap, documented at the call site: a fork whose crate version has no
matching tag (libredox) will make upgrade-forks.sh --to=<version> fail
loudly rather than reset onto a wrong ref -- the safe outcome. Threading
the upstream branch ref through as the rebase target is follow-up work.
2026-08-03 11:13:40 +03:00
..