Problem
The crates.io publisher rewrites Gear's forked Substrate dependencies to Gear-owned crates such as gp-wasm-interface and gp-runtime-interface. The current pins still point to the historical crates published from gear-tech/substrate branch cl/v1.1.x-crates-io:
sp-allocator -> gp-allocator 4.1.2sp-wasm-interface -> gp-wasm-interface 15.0.0sp-wasm-interface-common -> 15.0.0sp-runtime-interface -> gp-runtime-interface 18.0.0
gp-wasm-interface 15.0.0 depends on wasmtime 8.0.1, while the workspace has moved to newer Wasmtime through the Gear Substrate fork. This makes crates.io publish simulation fragile: Gear crates can build locally against the fork, then fail during crates.io verification after dependency rewriting pulls the old gp-* stack.
Proposed solution
Publish a refreshed set of Gear-owned Substrate crates from a new crates.io branch of the Gear Substrate fork, following the earlier cl/v1.0.x-crates-io and cl/v1.1.x-crates-io pattern.
At minimum, publish versions aligned with the current fork for:
gp-wasm-interfacesp-wasm-interface-commongp-runtime-interfacegp-runtime-interface-proc-macro, if required by the runtime-interface versiongp-allocator, if its dependency versions need to move with the interface crates
After publishing, update utils/crates-io/src/handler.rs in Gear to rewrite sp-wasm-interface, sp-wasm-interface-common, and sp-runtime-interface to the new published versions.
Validation should include:
cargo +stable run --release -p crates-io publish --simulate --registry-path /tmp/cargo-http-registry- crates.io verification of
gear-sandbox-interface, because it uses sp-runtime-interface and currently exposes the old Wasmtime API mismatch
Alternatives
Keep compatibility shims in Gear crates for the old gp-wasm-interface 15.0.0 API. That can unblock CI temporarily, but it leaves crates.io publication pinned to Wasmtime 8 and makes future Wasmtime migration work harder to reason about.
Problem
The crates.io publisher rewrites Gear's forked Substrate dependencies to Gear-owned crates such as
gp-wasm-interfaceandgp-runtime-interface. The current pins still point to the historical crates published fromgear-tech/substratebranchcl/v1.1.x-crates-io:sp-allocator->gp-allocator 4.1.2sp-wasm-interface->gp-wasm-interface 15.0.0sp-wasm-interface-common->15.0.0sp-runtime-interface->gp-runtime-interface 18.0.0gp-wasm-interface 15.0.0depends onwasmtime 8.0.1, while the workspace has moved to newer Wasmtime through the Gear Substrate fork. This makes crates.io publish simulation fragile: Gear crates can build locally against the fork, then fail during crates.io verification after dependency rewriting pulls the oldgp-*stack.Proposed solution
Publish a refreshed set of Gear-owned Substrate crates from a new crates.io branch of the Gear Substrate fork, following the earlier
cl/v1.0.x-crates-ioandcl/v1.1.x-crates-iopattern.At minimum, publish versions aligned with the current fork for:
gp-wasm-interfacesp-wasm-interface-commongp-runtime-interfacegp-runtime-interface-proc-macro, if required by the runtime-interface versiongp-allocator, if its dependency versions need to move with the interface cratesAfter publishing, update
utils/crates-io/src/handler.rsin Gear to rewritesp-wasm-interface,sp-wasm-interface-common, andsp-runtime-interfaceto the new published versions.Validation should include:
cargo +stable run --release -p crates-io publish --simulate --registry-path /tmp/cargo-http-registrygear-sandbox-interface, because it usessp-runtime-interfaceand currently exposes the old Wasmtime API mismatchAlternatives
Keep compatibility shims in Gear crates for the old
gp-wasm-interface 15.0.0API. That can unblock CI temporarily, but it leaves crates.io publication pinned to Wasmtime 8 and makes future Wasmtime migration work harder to reason about.