Support Workspace Releases

[jan-auer]

In workspace projects, it is often desired to create coordinated releases with all package versions bumped at the same time. This includes upgrading versions in dependent crates. It would be great to have some sort of workspace flag, that performs all upgrades in a single commit (and tag).

---

Maintainer Notes

Steps

• Make core functionality independent of CWD
• Properly update lock file in a workspace
• Verify / update corresponding version for path dependencies #77 Verify / update corresponding version for path dependencies
• Create clap-cargo to at least contain workspace flags, making the processing of cargo-metadata reusable for other plugins
• Support for cascading configurations #93 Figure out config semantics
• Support processing workspaces

[jan-auer]

If you like, I could start by putting a PR for this together. After looking at the code base, I think this would need some more refactoring. I would propose to move to cargo and toml-edit, and then add workspace updates in the next step.

[sunng87]

Cool! Workspace support is always welcomed. Can toml-edit retain the format or any comments in toml file? That's the reason I was manually update the cargo file.

[jan-auer]

In the latest version it can. It is what cargo-edit uses under the hood.

I’ve got a local experiment running, will try to clean it up over the next days and create a pull request.

[sunng87]

Thanks @jan-auer . Looking forward to your PR.

[spacekookie]

Is there any news on this? This is currently breaking my workflow quite massively 🙁

[ufoscout]

This is interesting. Anyway, to be really useful, it should handle also dependencies specified by an internal "path":

[dependencies]
intra_workspace_lib = { path = "../intra_workspace_lib" }

@jan-auer
any progress with your PR?

[jan-auer]

@ufoscout Unfortunately I haven't had enough time lately, and it turned out to be a major refactor. Not sure when I'll get back to this...

[spacekookie]

@ufoscout @jan-auer I started working on this: https://github.com/spacekookie/cargo-ws-release

At the moment it's non functional but I will try to finish it next week (before RustConf craziness 😬)

It's approach is to build a dependency graph between workspace dependencies so that a release can bump appropriate versions in referencing crates.

There are a few simple issues someone could tackle if they wanted to help out before that.

[sunng87]

@spacekookie that was great! Do you think it's good idea to make it a library, which generates an iterator that walks through the cargo workspace? We can then call cargo release on each crate iteratively.

[spacekookie]

@sunng87 well, just calling cargo release on each crate in the workspace isn't enough though. The big problem I'm trying to solve is the updating of dependency versions after an update.

But yea, turning it into a library and integrating it into cargo release is probably not a bad idea down the road

[sunng87]

yea, I think transform cargo-ws-release into a library can make it easier to integrate into cargo-release. Also I believe it could benefit some more scenarios.

[epage]

Progress

• Some parts of cargo-release are now relative to a manifest path rather than assuming CWD. More work to be done here
• With Switch away from regex-based file editors #91, cargo-release will properly update the lock file within a workspace

Once I finish with #77, cargo-release will be able to handle releasing a crate-at-a-time within a workspace. Once the rest of cargo-release works off manifest path, it could then easily be extended to support a release-all-at-once.

[spacekookie]

@epage have you had a look at spacekookie/cargo-ws-release#9 ?

[epage]

I had looked at cargo-ws-release but did not notice the PR. I'm unsure if ill get to adding --all support or just add minimal workspace support and the ground work for --all. My use case has me releasing each crate individually since my workspaces tend to have a stable -core separated from unstable implementations.

[epage]

So not ready to work directly on this yet but starting to give it some thought. For example, I think I'm going to create a clap-cargo crate that provides StructOpt structs for each set of flags (manifest path, workspace flags, etc). A user can just flatten them into their StructOpt struct like clap-verbosity.

I would want an optional feature to integrate with cargo-metadata to provide the information. For example, workspace support involves the following flags

• manifest-path
• all
• package
• exclude

We could provide a function on the workspace struct that partitions the cargo_metadata::Metadata::workspace_members into "process" and "exclude" sets based on the interaction of the above flags.

So one thing I'll need to know is how these flags interact. If anyone knows already, great! Otherwise, I'll have to either figure it out empirically or by digging into the code.

Examples of things to know

• When interacting with other workspace flags, does cargo assume anything special when manifest-path is not specified?
• If the current manifest is not the workspace root, it defaults to only the package in the manifest. Does specifying package override that? error? add? Is package repeatable?

EDITS:

• cargo's flag definitions are at command_prelude

[epage]

clap-cargo now exists.

[epage]

We now have layered config, including a config in the workspace root. See #111