Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Bump bytes crate to 0.6 #440

wants to merge 1 commit into from

Conversation

paolobarbolini
Copy link

No description provided.

@tesaguri
Copy link
Contributor

tesaguri commented Nov 4, 2020

bytes is not a public dependency of http now, so the minor version bump is not necessary (see #369).

@dekellum
Copy link
Contributor

dekellum commented Nov 4, 2020

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. bytes = ">= 0.5, < 0.7" . Yes, by default the same duplication will occur, but at least consumers have the option of using Cargo.lock to use bytes 0.5.6 and avoid the duplicate.

@tesaguri
Copy link
Contributor

tesaguri commented Nov 4, 2020

Some users of http as a public dependency, like attohttpc and http-types (via hyperium_http feature), do not depend on bytes, so I think a minor version bump is undesirable for them.

@dekellum
Copy link
Contributor

dekellum commented Nov 4, 2020

See also hyperium/http-body#29. That bytes dependency is public. If this PR (82418a8) was released as is, current hyper (which depends on both http and http-body, as well as bytes directly) users would end up with duplicate bytes crates, without necessarily having any bytes dependency themselves.

@hawkw
Copy link
Contributor

hawkw commented Nov 4, 2020

@dekellum I'm quite sure a new hyper will not be released until http-body also depends on bytes 0.6.

@dekellum
Copy link
Contributor

dekellum commented Nov 4, 2020

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, cargo update on an existing hyper 0.13 application will result in duplicate of bytes crate. If on the other hand, you release the bytes upgrade as http 0.3.0, then no duplicate now, and no duplicates with mass upgrade to hyper 0.14 with its tokio, http, http-body, bytes deps.

@seanmonstar
Copy link
Member

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.

@dekellum
Copy link
Contributor

dekellum commented Nov 4, 2020

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 cargo update -p bytes:0.6.0 --precise 0.5.6 and keeping your lock file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants