-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bump bytes crate to 0.6 #440
Conversation
|
A MINOR version bump (0.3.0) may not be necessary as you say, but is it really desirable to introduce bytes 0.6 in a patch release of http? As it will end up being a duplicate with other crates remaining dependent on bytes 0.5 for quite some time, I don't think its desirable to introduce it that way. It might be better to release the change in http 0.3.0 (as in da252dd) so that h2, hyper, and related crates can update to it in their own MINOR releases. If there is some motivation for releasing it as a patch, then consider broadening the dependency instead, e.g. |
Some users of |
See also hyperium/http-body#29. That |
@dekellum I'm quite sure a new |
Sure, but new hyper will be 0.14 (a MINOR bump) for new tokio, etc., right? My more limited point is just that if this PR was released as is, |
I've forgotten the exact details cargo will do if we use a version range... If other crates in the dependency graph want 0.5.x, will it just keep it to 1 copy? If so, I find that preferable. |
Sadly, no. Cargo will go for maximum versions, not to minimize duplicates. Thus I'd prefer this in http 0.3.0 (edit: or 1.0.0), but if it must be done as a patch release then at least with the range, one can avoid the duplicate by something like |
No description provided.