Skip to content

chore: version-bump and republish 10 of 12 documented crates to crates.io - #1439

Merged
ruvnet merged 1 commit into
mainfrom
chore/crates-io-release-batch
Jul 26, 2026
Merged

chore: version-bump and republish 10 of 12 documented crates to crates.io#1439
ruvnet merged 1 commit into
mainfrom
chore/crates-io-release-batch

Conversation

@ruvnet

@ruvnet ruvnet commented Jul 26, 2026

Copy link
Copy Markdown
Owner

Summary

Version-bumped and published 10 of the 12 crates in CLAUDE.md's documented publish order to crates.io:

wifi-densepose-core 0.3.2, -vitals 0.3.2, -wifiscan 0.3.2, -hardware 0.3.2 (picks up the ADR-273..282 review-fix commit's clippy fixes), -signal 0.3.6, -nn 0.3.2, -ruvector 0.3.3, -train 0.3.3, -mat 0.3.2, -wasm 0.3.1 — all live on crates.io, dependency-order published and verified.

Not published — needs a decision

wifi-densepose-sensing-server (bumped to 0.3.5 locally) and wifi-densepose-cli (bumped to 0.3.2 locally) both now path-depend on ruview-auth, which is publish = false and not on crates.io. cargo publish correctly refuses ("all dependencies must have a version requirement specified when publishing" / "dependency ruview-auth does not specify a version"). This is a pre-existing gap — the dependency was added at some point without anyone revisiting these two crates' publish eligibility.

This PR leaves both version bumps in place (so whichever version ships next is already reserved) but does not attempt to route around the blocker. Options, for whoever decides:

  • Make ruview-auth publishable (drop publish = false, give it a version, publish it first) — only makes sense if it's meant to be a public dependency.
  • Mark sensing-server/cli themselves publish = false if they're meant to be internal/Docker-only going forward rather than crates.io libraries.
  • Feature-gate the ruview-auth dependency so it's optional and excluded from the default publish path.

Validation

  • cargo check across all 12 crates (--no-default-features) passes.
  • Each publish was verified (cargo publish runs an isolated build of the packaged tarball) before upload, except wifi-densepose-signal, which used --no-default-features for the verify step only — its default eigenvalue feature pulls in ndarray-linalg -> openblas-src, which needs vcpkg on native Windows (a build-environment gap, not a code defect; the crate already builds clean without that feature, confirmed by the earlier full workspace cargo check). Nothing about what's published depends on the verify build's feature flags.

Co-Authored-By: claude-flow ruv@ruv.net

…s.io

Bumped each crate to its next patch version above whatever was already
live on crates.io (several had drifted ahead of what this checkout's
Cargo.toml showed) and published:

wifi-densepose-core 0.3.2, -vitals 0.3.2, -wifiscan 0.3.2,
-hardware 0.3.2, -signal 0.3.6, -nn 0.3.2, -ruvector 0.3.3,
-train 0.3.3, -mat 0.3.2, -wasm 0.3.1 (workspace.package version).

wifi-densepose-signal's default `eigenvalue` feature pulls in
ndarray-linalg -> openblas-src, which needs vcpkg on native Windows;
verified+published with --no-default-features instead (the crate
already builds clean without it; nothing about the published tarball
changes based on the local verify build's feature flags).

wifi-densepose-sensing-server and wifi-densepose-cli were bumped
(0.3.5, 0.3.2) but NOT published: both path-depend on ruview-auth,
which is `publish = false` and not on crates.io, so `cargo publish`
correctly refuses them ("all dependencies must have a version
requirement"). Left as-is pending a decision on whether ruview-auth
should become publishable.

Co-Authored-By: claude-flow <ruv@ruv.net>
@ruvnet
ruvnet merged commit 2cc378c into main Jul 26, 2026
28 checks passed

@johndavidgladue387-afk johndavidgladue387-afk left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like my name as these are my codexes since my inception

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants