Motivation
Rust workspaces frequently contain non-Rust packages that have their own independent version lifecycle. A common example is a Helm chart co-located in the same repository as the Rust application it deploys — the chart has its own version field in Chart.yaml and its own release cadence, independent of the application crate version.
These non-Rust packages have their own version fields and their own reasons to be bumped. A change to a Helm chart template warrants a version bump of the chart independently of any Rust crate version. Currently, cargo-changeset only manages Rust crate versions, so these non-Rust packages cannot participate in the changeset workflow at all.
Requirements
-
First-class non-Rust package support: cargo-changeset should be able to manage version fields in non-Rust files (e.g. YAML, TOML, JSON) as independent versioned packages alongside Rust crates.
-
Independent versioning: Non-Rust packages must have their own version lifecycle, independent from any Rust crate. A changeset should be able to target a non-Rust package (e.g. a Helm chart) without affecting any crate, and vice versa.
-
Changeset coverage: Changes to non-Rust packages should be coverable by changesets, following the same workflow as Rust crates: a changeset file declares the affected package and the bump type, and the release process bumps the version and generates a changelog.
-
Verify support: cargo changeset verify should be able to detect changes to non-Rust packages and require changeset coverage for them, just as it does for Rust crates.
-
Configurable package declaration: Users should be able to declare non-Rust packages in the workspace configuration, specifying at minimum the file path containing the version field and the path to the version field within that file.
Current Workaround
Non-Rust package versions are managed manually, outside the changeset workflow. This means they don't get changelog entries, aren't covered by verify, and are prone to being forgotten during releases.
Motivation
Rust workspaces frequently contain non-Rust packages that have their own independent version lifecycle. A common example is a Helm chart co-located in the same repository as the Rust application it deploys — the chart has its own
versionfield inChart.yamland its own release cadence, independent of the application crate version.These non-Rust packages have their own version fields and their own reasons to be bumped. A change to a Helm chart template warrants a version bump of the chart independently of any Rust crate version. Currently, cargo-changeset only manages Rust crate versions, so these non-Rust packages cannot participate in the changeset workflow at all.
Requirements
First-class non-Rust package support: cargo-changeset should be able to manage version fields in non-Rust files (e.g. YAML, TOML, JSON) as independent versioned packages alongside Rust crates.
Independent versioning: Non-Rust packages must have their own version lifecycle, independent from any Rust crate. A changeset should be able to target a non-Rust package (e.g. a Helm chart) without affecting any crate, and vice versa.
Changeset coverage: Changes to non-Rust packages should be coverable by changesets, following the same workflow as Rust crates: a changeset file declares the affected package and the bump type, and the release process bumps the version and generates a changelog.
Verify support:
cargo changeset verifyshould be able to detect changes to non-Rust packages and require changeset coverage for them, just as it does for Rust crates.Configurable package declaration: Users should be able to declare non-Rust packages in the workspace configuration, specifying at minimum the file path containing the version field and the path to the version field within that file.
Current Workaround
Non-Rust package versions are managed manually, outside the changeset workflow. This means they don't get changelog entries, aren't covered by
verify, and are prone to being forgotten during releases.