To make a long story short, I updated a bytes dependency from 0.5 to 0.6 in a library crate, and I got build errors further down the dependency tree, which rust hinted might be due to multiple versions being pulled in, and indeed tokio-test still pulls in 0.5.
I thought that the idea was that 0.6.X should be backwards compatible with 0.5.X? Or is special because major version is 0? Is tokio-test forcing 0.5 in some manner?
The meaning of semver in Rust is that if the first non-zero number changes then it's a breaking change.
So 0.5.x to 0.6.x is breaking. But 1.5.x to 1.6.x isn't.
Note that this is a difference from the Semver spec, which says
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
It is frequently convenient to define compatibility between releases of something that has not yet reached 1.0, so I assume that's why Cargo works the way it does, but it's a subtlety that occasionally confuses people. Pretty sure if you dig you can find lots of arguments for why it should / should not work this way.
The way that Cargo treats versions prior to 1.0 is that every number is shifted to the right one. So 0.x to 0.(x+1) is breaking, while 0.x.y to 0.x.(y+1) is not.
Cargo treats the first non-zero component as “major,” so 0.0.1 to 0.0.2 is also considered “breaking.”
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.