Summary
The v* release tag drives five publish workflows — PyPI, npm, RubyGems, NuGet, and Maven Central — but there is no workflow that publishes the Rust crates. grep -r "cargo publish\|CARGO_REGISTRY_TOKEN" .github/ returns nothing.
The result after the 0.2.0 release:
| Registry |
Version |
| PyPI |
0.2.0 |
| npm |
0.2.0 |
| RubyGems |
0.2.0 |
| NuGet |
0.2.0 |
| Maven Central |
0.2.0 |
crates.io rustwright |
0.1.1 |
crates.io rustwright-core |
0.1.1 |
Cargo.toml at the v0.2.0 tag already declares version = "0.2.0", so the crates are versioned for the release — they were simply never pushed.
Why this is worth fixing
This is a Rust project whose own crates are the thing most Rust users would reach for first, and the README carries crates.io download badges. Right now those badges advertise a version that is a full release behind the bindings. Anyone who finds the project through crates.io gets 0.1.1 and none of the 0.2.0 fixes — including the evaluate() statement-forms restoration.
It is also the only registry in the set that depends on someone remembering to run a command by hand, which is exactly the step that gets skipped.
Suggested fix
Add release-crates.yml alongside the other five, gated the same way (github.ref_type == 'tag', publish only on a tag push or a non-dry-run dispatch), publishing rustwright-core first and then rustwright, since the latter depends on the former and crates.io needs the dependency to be live before the dependent will verify.
Worth handling explicitly in that workflow:
- crates.io publishes are permanent — a version can be yanked but never replaced — so the dry-run path should use
cargo publish --dry-run and the real path should run only from a tag.
- The two crates need an ordered publish with a wait, because the index takes a short while to expose a freshly published version to the dependent crate's resolver.
Immediate state
0.2.0 is published everywhere else. The crates can be pushed for 0.2.0 without any version bump, since the manifest is already at 0.2.0.
Summary
The
v*release tag drives five publish workflows — PyPI, npm, RubyGems, NuGet, and Maven Central — but there is no workflow that publishes the Rust crates.grep -r "cargo publish\|CARGO_REGISTRY_TOKEN" .github/returns nothing.The result after the 0.2.0 release:
rustwrightrustwright-coreCargo.tomlat thev0.2.0tag already declaresversion = "0.2.0", so the crates are versioned for the release — they were simply never pushed.Why this is worth fixing
This is a Rust project whose own crates are the thing most Rust users would reach for first, and the README carries crates.io download badges. Right now those badges advertise a version that is a full release behind the bindings. Anyone who finds the project through crates.io gets 0.1.1 and none of the 0.2.0 fixes — including the
evaluate()statement-forms restoration.It is also the only registry in the set that depends on someone remembering to run a command by hand, which is exactly the step that gets skipped.
Suggested fix
Add
release-crates.ymlalongside the other five, gated the same way (github.ref_type == 'tag', publish only on a tag push or a non-dry-run dispatch), publishingrustwright-corefirst and thenrustwright, since the latter depends on the former and crates.io needs the dependency to be live before the dependent will verify.Worth handling explicitly in that workflow:
cargo publish --dry-runand the real path should run only from a tag.Immediate state
0.2.0 is published everywhere else. The crates can be pushed for 0.2.0 without any version bump, since the manifest is already at 0.2.0.