Outdated dependencies

[sdr5b]

There are many outdated dependencies in this software. Take a look in the fork with enabled dependabot: https://github.com/sdr5b/OpenPulseHF/pulls?q=is%3Apr+state%3Aopen

This is also the reason why you get this warning

Node.js 20 is deprecated.

in here https://github.com/dc0sk/OpenPulseHF/actions/runs/35468492381

[dc0sk]

Thanks — the Node 20 warning is real and worth fixing. Splitting the report in two, because the two
halves have different causes and only one of them is about dependencies.

The Node 20 warning is GitHub Actions, not Cargo

It is not caused by outdated Rust dependencies. It comes from the runtime of the GitHub Actions
themselves. Every action in this repo is pinned to a full commit SHA, deliberately — see the
header note in .github/workflows/ci.yml — which is good supply-chain practice and also means each
action is frozen at whatever Node runtime that SHA shipped with. The fix is to re-pin the SHAs to
newer releases, entirely independent of Cargo.toml.

The pinned set is:

actions/cache, actions/checkout, actions/download-artifact, actions/upload-artifact,
dtolnay/rust-toolchain, softprops/action-gh-release, Swatinem/rust-cache, taiki-e/install-action

I have not identified which specific action emits the warning on the run you linked, so I am not
going to guess at it here — that is the first thing to establish, since it decides how many pins need
moving. This is a small, self-contained task and a good candidate to just do.

The Rust dependency half needs different evidence

Here I would rather not act on a fork's Dependabot queue directly, for two reasons:

• "Outdated" and "vulnerable" are different claims. cargo audit already runs inside
  scripts/gate.sh on every gate, so a security-relevant dependency would fail the build today. If
  Dependabot has surfaced an advisory that our audit is not catching, that is a much more urgent
  report than "N versions behind", and I would like to see it specifically.
• Some pins here are deliberate, and a bulk bump would quietly undo decisions with reasons
  attached — the toolchain is pinned to a required rustc version with a preflight check, and this
  codebase has a documented history of a dependency-shaped change invalidating a gate.

So: if you can point at specific crates where the update matters — an advisory, a bug fix you
need, or a version wall you have hit — that is directly actionable and I will take it. A list of
"behind latest" I would want to work through selectively rather than wholesale.

Not a brush-off: the Node 20 half I think should just be fixed, and I would rather do that as its own
change than bundle it with a Cargo sweep.

One practical note, since you are running a fork with Dependabot: this repo's CI is unusual —
ci.yml is scoped to release/** branches and the full workspace gate runs post-merge on main
rather than pre-merge (see #1144). So green Dependabot PRs in a fork will not have exercised the same
gates this repo relies on.

🤖 Generated with Claude Code

https://claude.ai/code/session_0188ATCj6DZ9aRVQ2vSirua6

[sdr5b]

I know AI often have problems with such updates. Its thinking too much and too deep into this. Such updates can be viewed like OS updates. People also just install their updates on their computers and do not and should not have to do a deep research at every single update.
The longer such updates are not installed, the more work it is in most cases to get back on the recent stable release track.

Solution is simple. Enable dependabot, it then start to create PullRequets. In most cases people can just merge them. If something need code changes because of a new version, its in general a good idea to make those changes to the project instead of staying at a old version.