Closed ereichert closed 8 years ago
I can only speak for myself. It's often that I search github for code and never make it to crates.io before using a dependency. It has happened that I've grabbed an older version of a crate because the version specified by the README on github had not been updated and the older version didn't match the docs. Obviously that can be a bit frustrating.
That being said, an update of the version number should be automated during the build, or something like that, using the version number in the cargo.toml.
Just a suggestion.
Hmm. I'm not sure i follow. If you use 0.1
in your Cargo.toml, then it should grab the latest version number.
It does. That's actually how I noticed it was 1.5 instead of .1.
I've been burned too many times by some minor change that occurred in a patch version. So I pin my dependencies to the full version when I'm getting close to the end of a development cycle.
I'm sympathetic to being bitten by patch versions, but I don't intend to release breaking changes in a patch version upgrade (if I do and it's brought to my attention, I'll yank it). More than that, I maintain that this is a recipe for creating stale version numbers. I either need to write scripts that update the version number automatically in both the README and the source code, or remember to update them manually.
A possible alternative to your process: during development, stick with the 0.x
version constraints. When you're getting close to the end of the dev cycle, do a cargo update
, check that everything works and then pin down the version numbers in Cargo.toml
based on what's in your Cargo.lock
. (I personally find it unfortunate that you have to do this. People shouldn't be releasing breaking changes in patch updates.)
Hmm. Thanks! But why exactly should we do this? In my opinion, it's a maintenance burden that is bound to become stale.