Bump itertools version to allow 0.12 #963
Conversation
It is never desired to publish crates with an unbounded upper version range, as there is no guarantee that future semver-breaking i.e. when this This version-range model allows |
caspermeijn
left a comment
caspermeijn
left a comment
There was a problem hiding this comment.
Please rebase to latest master to fix CI
| bytes = { version = "1", default-features = false } | ||
| heck = "0.4" | ||
| itertools = { version = ">=0.10, <0.12", default-features = false, features = ["use_alloc"] } | ||
| itertools = { version = ">=0.10, <0.13", default-features = false, features = ["use_alloc"] } |
There was a problem hiding this comment.
Personally, I think this syntax explains better the intent of the version bounds.
| itertools = { version = ">=0.10, <0.13", default-features = false, features = ["use_alloc"] } | |
| itertools = { version = ">=0.10, <=0.12", default-features = false, features = ["use_alloc"] } |
There was a problem hiding this comment.
@caspermeijn one thing that might be hiding is that this version range, whether it is written as <0.13 or <=0.12, allows 0.12.99999. Some folks find that confusing with the second format, though I also prefer to read the version that is included rather than the one that is excluded 👍
There was a problem hiding this comment.
Well, the intention is to include/allow 0.12 series, so I prefer to write is the suggested way.
|
Fixed in #948 |
3 participants
Ran into a dependency conflict with using itertools 0.12 in our project that also depends on prost.
When I ran the tests everything appeared to work, so I'm not sure what the purpose of the
<0.12restriction was.