Skip to content

fix(release): use cargo-workspace + linked-versions plugins - #38

Merged
non7top merged 2 commits into
masterfrom
fix/release-please-workspace-plugins
Sep 26, 2026
Merged

non7top merged 2 commits into
masterfrom
fix/release-please-workspace-plugins

Conversation

@non7top

@non7top non7top commented Sep 26, 2026

Copy link
Copy Markdown
Owner

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, not version.workspace = true), and the next run got further — it correctly walked and updated all four members. But it then also tried to treat the root Cargo.toml as a package manifest (since our config had a single "." package entry with release-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's release-please-config.json. For a pure virtual workspace root, the right shape is:

  • One "packages" entry per member directory (core, app, tools/pack-cities, tools/pack-flags), not a single "." entry.
  • The cargo-workspace plugin, which understands a virtual root and manages the shared Cargo.lock.
  • The linked-versions plugin with merge: true, which keeps all four releasing together as one PR/tag — matching what the shared version.workspace = true gave us before this whole detour started.

.release-please-manifest.json is now keyed by member path to match.

One behavior change worth flagging: no changelog-path override this time, so (confirmed against rust_icu's actual repo layout) each member gets its own CHANGELOG.md in its own directory, rather than one shared root file. Went with the default rather than guess at changelog-path's path-resolution rules to force a shared file.

Builds on #37 (merged).

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.
@github-actions

Copy link
Copy Markdown
Contributor

Windows build ready for 74b47c8 (17.3 MB):

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.
@non7top

non7top commented Sep 26, 2026

Copy link
Copy Markdown
Owner Author

Addressed non7top/release-please-forecast#20, which this PR's switch to the cargo-workspace/linked-versions plugins (no "." manifest key) exposed:

The package-name: core line won't take effect until gh-workflows#1 merges (it's still pointed at @main), so the next preview run here will keep warning until then.

@github-actions

Copy link
Copy Markdown
Contributor

Windows build ready for 81b0c60 (17.3 MB):

Download and run it. No unpacking, no installer, no runtime needed.

@github-actions

Copy link
Copy Markdown
Contributor

🤖 release-please PREVIEW

What merging this PR into master would trigger:

🤖 I will create a release beep boop

0.5.0

0.5.0 (2026-09-26)

Bug Fixes

  • release: give each crate a literal version instead of workspace-inherited (bbe21e3)
  • release: give each crate a literal version instead of workspace-inherited (ceab4bc)
  • release: leave the literal versions at 0.1.0, not 0.5.0 (3ef4898)
  • release: use cargo-workspace + linked-versions plugins (the merge commit GitHub would create for this PR)

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 bb7d259 merged into master at bbe21e3, with the PR title read as fix(release): use cargo-workspace + linked-versions plugins · Full run

@non7top
non7top merged commit d58ac55 into master Sep 26, 2026
5 checks passed
@non7top
non7top deleted the fix/release-please-workspace-plugins branch September 26, 2026 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant