Description
The workspace is pinned to Rust 1.95.0 while current stable is 1.98.1 (released 2026-09-01), and the lockfile has drifted well behind the registry. Bump the toolchain, take the available dependency updates, and fix whatever the newer compiler and clippy surface.
Toolchain
.tool-versions is the single source of truth CI greps for the Rust version, but two other places hardcode it and must move in step:
examples/app-demo/crates/app-demo-adapter-fastly/rust-toolchain.toml
build_tool_versions() in crates/edgezero-cli/src/generator.rs, which pins the Rust version written into every newly scaffolded app
That last one had already drifted. Its doc comment says "Versions are pulled from this repo's own .tool-versions. When we bump those, we bump these" — a manual convention with no enforcement. A test should assert the two agree so this can't silently diverge again.
Expected friction
The workspace enables the whole clippy restriction group at deny:
restriction = { level = "deny", priority = -1 }
Every lint added to that group in any release becomes a build error, so a three-minor-version jump lands three releases of new lints at once. Each needs triaging into "fix the code" vs. "the lint conflicts with something the project deliberately does".
Dependencies
Refresh both lockfiles — the root workspace and the excluded examples/app-demo one, which cargo will not touch from the root — and check whether any major-version bumps are worth taking.
Two things to weigh rather than take on sight:
- Anything that changes a persisted format (config-envelope hashes in particular) needs the pinned-hash tests to still pass first.
- A major bump on a direct dependency does not always consolidate. If a transitive dependency still resolves the older major, taking the newer one adds a second copy instead of replacing the first — check
cargo tree -i <crate>@<version> before assuming a bump is an improvement.
A "blocked by the runtime" verdict is a fact about the runtime version that happens to be installed. Re-check whether a newer runtime lifts it before recording it as a hold.
Also in scope
examples/app-demo is still on edition 2021 while the main workspace and the scaffold templates are on 2024. New apps are generated on 2024, so the reference app is the odd one out — migrate it.
Acceptance
- All five CI gates pass on 1.98.1
- All three wasm targets compile (
wasm32-wasip1 / wasm32-wasip2 / wasm32-unknown-unknown)
examples/app-demo builds and tests on edition 2024
- Newly scaffolded apps pin the same Rust version, tool versions and shared crate majors as this repo, enforced by tests rather than by a comment asking future maintainers to keep them in step
- No dependency left a major behind without a reason recorded at the pin
Description
The workspace is pinned to Rust 1.95.0 while current stable is 1.98.1 (released 2026-09-01), and the lockfile has drifted well behind the registry. Bump the toolchain, take the available dependency updates, and fix whatever the newer compiler and clippy surface.
Toolchain
.tool-versionsis the single source of truth CI greps for the Rust version, but two other places hardcode it and must move in step:examples/app-demo/crates/app-demo-adapter-fastly/rust-toolchain.tomlbuild_tool_versions()incrates/edgezero-cli/src/generator.rs, which pins the Rust version written into every newly scaffolded appThat last one had already drifted. Its doc comment says "Versions are pulled from this repo's own
.tool-versions. When we bump those, we bump these" — a manual convention with no enforcement. A test should assert the two agree so this can't silently diverge again.Expected friction
The workspace enables the whole clippy
restrictiongroup atdeny:Every lint added to that group in any release becomes a build error, so a three-minor-version jump lands three releases of new lints at once. Each needs triaging into "fix the code" vs. "the lint conflicts with something the project deliberately does".
Dependencies
Refresh both lockfiles — the root workspace and the excluded
examples/app-demoone, which cargo will not touch from the root — and check whether any major-version bumps are worth taking.Two things to weigh rather than take on sight:
cargo tree -i <crate>@<version>before assuming a bump is an improvement.A "blocked by the runtime" verdict is a fact about the runtime version that happens to be installed. Re-check whether a newer runtime lifts it before recording it as a hold.
Also in scope
examples/app-demois still on edition 2021 while the main workspace and the scaffold templates are on 2024. New apps are generated on 2024, so the reference app is the odd one out — migrate it.Acceptance
wasm32-wasip1/wasm32-wasip2/wasm32-unknown-unknown)examples/app-demobuilds and tests on edition 2024