The uuid crate has been in stable v1 for 4 month (9 if you include the alpha versions). It would be great to update it as it causes quite a few incompatibilities with other crates. Of course there are cheap (possibly optimized to nothing) ways to convert between the old and new UUIDs, but having to convert explicitly causes unnecessary friction.
Also as said here, this version should be the "last" to require a breaking update :
With uuid 1.0 we'll try to stay on that version "forever". There won't be a 2.0 unless there's a very compelling need for it. That means you should feel safe depending on Uuid in the public API of your libraries if you want to.
Solution
Set uuid's version to 1.x in Cargo.toml. I don't know if the minor version would benefit from being specified too. The breaking changes are described here.
@edgarogh we do have this on master for quite a while, and it will go into 0.16 release. This won't be fixed on 0.15 juniper however, as introduces breaking change.
The
uuid
crate has been in stable v1 for 4 month (9 if you include the alpha versions). It would be great to update it as it causes quite a few incompatibilities with other crates. Of course there are cheap (possibly optimized to nothing) ways to convert between the old and new UUIDs, but having to convert explicitly causes unnecessary friction.Also as said here, this version should be the "last" to require a breaking update :
Solution
Set
uuid
's version to 1.x inCargo.toml
. I don't know if the minor version would benefit from being specified too. The breaking changes are described here.I can work on that if you're interested.