Proper way to manage dependencies in crates

I am writing a crate which has a list of denedencies.
The problem is that I specify the latest versions of dependencies, while some of the users have to use older ones.
For example, I had to specify lower version of syn crate.
Before I used to only write binaries or crates deeply linked to them in the same namespace, so I didn't have to deal with this problem.

What is the correct way of specifying the dependencies in crates, then?
Would be glad for any help!

My process is:

  • Add dependencies with cargo add. Or put whatever the most recent version of the crate is. Corresponding to whatever version you're reading the docs for.
  • Do nothing until someone specifically requests a lower version.

I think if you interrogate why you had to do this, then it will reveal something more interesting. If you aren't sure how to interrogate, then you can share the full progression that led to you decreasing the version, and maybe someone here can contextualize it for you.

1 Like

Thanks for the answer!
I had to do this because the user has very bureaucratic and strict rules on updating their dependencies.

It is your choice as a library maintainer to decide whether to support such use cases — this can be understood as a feature request. If they want your library to support compiling with a specific older dependency, that’s a request for the feature of relaxing your dependency requirement to accept an older version. Like any other feature request, it is up to you to decide whether doing so is worth the maintenance burden, constraint that you can't use newer features of that dependency, and risk of bugs in older versions that affect your uses of that dependency.

If you are choosing to support older dependencies, it would be wise to to test with those older dependencies too, to ensure you don’t accidentally depend on a newer feature. You can test this with

cargo +nightly update -Zdirect-minimal-versions
cargo test

to ensure that your tests pass when compiling with the lowest version you’ve requested. Note that this will modify the Cargo.lock file, so only do it on a throw-away copy (e.g. in a separate CI job).

1 Like