Repository navigation
fix(release): use cargo-workspace + linked-versions plugins - #38
Conversation
Plain release-type "rust" on package "." also failed once the literal- version fix (#37) let it get past each member: it then tried to treat the root Cargo.toml itself as a package manifest too, and ours is a pure virtual manifest (only [workspace], no [package] section) -- "is not a package manifest (might be a cargo workspace)". Confirmed against release-please's actual plugin source (src/plugins/cargo-workspace.ts, src/plugins/linked-versions.ts) and a real working example (google/rust_icu's release-please-config.json): a pure virtual workspace root needs one "packages" entry per member (keyed by directory, not ".") plus the cargo-workspace plugin (handles the virtual root and the shared Cargo.lock) and linked-versions with merge: true (keeps all four releasing together as one PR/tag, same as the shared version gave us before). .release-please-manifest.json is now keyed by member path to match. No CHANGELOG.md path override this time -- default behavior (confirmed against rust_icu) is one CHANGELOG.md per member directory rather than a single shared root one, which is simpler than guessing at changelog-path's path resolution to force a shared file.
|
Windows build ready for Download and run it. No unpacking, no installer, no runtime needed. |
Our manifest has no "." key since #37/this PR moved to the cargo-workspace + linked-versions plugins, so release-please-forecast was falling back to guessing the manifest's first key and preflight-warning about it on every preview (non7top/release-please-forecast#20, see #38 (comment)). The guess happens to be right here, since linked-versions with merge: true keeps core/app/tools/pack-* at one version, but naming it explicitly turns that guess into a stated fact instead. Needs non7top/gh-workflows#1 merged to take effect — release-please-preview.yml@main doesn't accept a package-name input yet.
|
Addressed non7top/release-please-forecast#20, which this PR's switch to the
The |
|
Windows build ready for Download and run it. No unpacking, no installer, no runtime needed. |
🤖 release-please PREVIEWWhat merging this PR into 🤖 I will create a release beep boop0.5.00.5.0 (2026-09-26)Bug Fixes
Miscellaneous Chores
This PR was generated with Release Please. See documentation. Two entries, one change: release-please reads both the commit on this branch and the merge commit GitHub will create, whose body is this PR title. Both really do land in the published changelog. Only the merge commit has no SHA to cite, because it does not exist yet. Predicted from |
Fixes the run that failed after #37 merged: https://github.com/non7top/sort4print/actions/runs/36226824050 —
release-please failed: is not a package manifest (might be a cargo workspace).What happened
#37 fixed the first crash (each member now has a literal
version, notversion.workspace = true), and the next run got further — it correctly walked and updated all four members. But it then also tried to treat the rootCargo.tomlas a package manifest (since our config had a single"."package entry withrelease-type: "rust"), and our root is a pure virtual manifest (only[workspace], no[package]section) — so that check failed.The fix
Checked release-please's actual plugin source (
src/plugins/cargo-workspace.ts,src/plugins/linked-versions.ts) and a real working example,google/rust_icu'srelease-please-config.json. For a pure virtual workspace root, the right shape is:"packages"entry per member directory (core,app,tools/pack-cities,tools/pack-flags), not a single"."entry.cargo-workspaceplugin, which understands a virtual root and manages the sharedCargo.lock.linked-versionsplugin withmerge: true, which keeps all four releasing together as one PR/tag — matching what the sharedversion.workspace = truegave us before this whole detour started..release-please-manifest.jsonis now keyed by member path to match.One behavior change worth flagging: no
changelog-pathoverride this time, so (confirmed againstrust_icu's actual repo layout) each member gets its ownCHANGELOG.mdin its own directory, rather than one shared root file. Went with the default rather than guess atchangelog-path's path-resolution rules to force a shared file.Builds on #37 (merged).