Synchronising versions of 3rd party dependencies a workspace

How do you maintain versions of 3rd party dependencies in crates within a workspace?

For example, I have A,B,C,D crates all in a workspace and A,B and D use serde. I could lock it to the current version, but that's a pain as I need to update it in three places.

I could use a wide semver range (e.g. "1") but that's dangerous.

Maven allows you to define your version numbers in the parent pom and the children inherit it - is there such a thing in rust lang?

I really don't want to mess around with regular expressions :slight_smile:

For a workspace, the Cargo.lock file sets the exact versions used, across all crates in the workspace. The only time you need to make file changes changes across multiple crates is when you are editing the Cargo.tomls to upgrade to a new incompatible (major) version (because major versions are the only case where Cargo might link multiple different versions of a library). That's a rare event for stable libraries — serde has been 1.0.x for over four years.

Concrete example: If workspace/a/Cargo.toml specifies serde = "1.0.36" and workspace/b/Cargo.toml specifies serde = "1.0.100" then both crates a and b will be compiled against the same serde dependency as specified in the Cargo.lock file, which will always be at least 1.0.100 and will usually be the most recent compatible version (as of the last time either the lock file was deleted or cargo update was run).

In general, Cargo.toml versions specify what versions your crates can compile against and Cargo.lock specifies what they will compile against. You should not be updating Cargo.toml versions to newer ones except when you know a certain minor-version feature or patch-version bug fix is necessary for your libraries.

1 Like

Thanks for the reply. So serde was a bad example :slight_smile: - there are plenty of fast moving crates, and the problem remains: I want all crates to have the same version. Is this just not a solved problem?

I understand your point about Cargo normalising to the latest safe version based on server, but that doesn’t help the issue.

Why is this a problem? Neatness I guess. Also explicitness - if a is 0.3.5 and b uses 0.4 - why? Is there an incompatible API change that means a can’t upgrade? I now need to start biting these things down.

I think you can use cargo-edit as a tool to modify your Cargo.toml files across the workspace, but I haven't yet tried it myself.

1 Like

Ah ok, I’ll look into that - thanks!

It's not a direct solution but the pattern espoused by cargo-hakari may offer inspiration or education towards your goal.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.