googleapis / release-please

generate release PRs based on the conventionalcommits.org spec
https://www.conventionalcommits.org
Apache License 2.0
4.44k stars 331 forks source link

cargo-workspace plugin can't handle `version.workspace` #2111

Open mrcjkb opened 8 months ago

mrcjkb commented 8 months ago

Environment details

Steps to reproduce

Use release-please on a Rust project with

# root Cargo.toml
members = [
  "subcrate",
]

[workspace.package]
version = "<version>"
#subcrate/Cargo.toml
[package]
name = "subcrate"
version.workspace = true

And release-please configured accordingly, e.g.

{
    ".": "<version>",
    "subcrate": "<version>"
}
{
  "plugins": ["cargo-workspace"],
  "packages": {
    ".": {
        "release-type": "rust"
    },
    "subcrate": {
        "release-type": "rust"
    }
  }
}

See for example this project (permalink), or this example from the cargo book.

Expected behaviour

release-please updates the workspace.package.version in the root Cargo.toml

Actual behaviour

release-please fails with

cargo-workspace (mrcjkb/tuxedo-rs): package manifest at subcrate/Cargo.toml has an invalid [package.version]
c-thiel commented 3 weeks ago

@mrcjkb and anyone else stumbling over this, the next best thing I could do is at least link the versions as describe here: https://github.com/googleapis/release-please/blob/main/docs/manifest-releaser.md#linked-versions

While this results in 3 Changelogs, at least we get one PR for all crates and simultaneous version upgrades. It looks something like this now: https://github.com/hansetag/iceberg-catalog/blob/9b9cb2257cd1294086ab3cd5b0a82a5cdda78748/release-please/release-please-config.json