-
Notifications
You must be signed in to change notification settings - Fork 118
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
Make Hyper v0 support optional #294
Comments
PaulDance
added a commit
to JustRustThings/boring
that referenced
this issue
Dec 6, 2024
Closes cloudflare#294. Requires breaking changes, but only regarding the `hyper1` feature's enabled module path; the default v0 is still preserved. What is proposed here in order to achieve the objective is to have both modules be re-exported when the other feature is not enabled, and have them be made public when both features are enabled at the same time. This way, the features should be kept additive: all four combinations are supported. It enables dependency de-duplication when consuming it. Signed-off-by: Paul Mabileau <[email protected]>
PaulDance
added a commit
to JustRustThings/boring
that referenced
this issue
Dec 7, 2024
Closes cloudflare#294. Requires breaking changes. The default v0 is changed in favor of v1, but v0 is still kept available, just in a forced module path. It enables dependency de-duplication when consuming it. Signed-off-by: Paul Mabileau <[email protected]>
PaulDance
added a commit
to JustRustThings/boring
that referenced
this issue
Dec 7, 2024
Closes cloudflare#294. Requires breaking changes. The default v0 is changed in favor of v1, but v0 is still kept available, just in a forced module path. It enables dependency de-duplication when consuming it. Signed-off-by: Paul Mabileau <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Dear maintainers,
Now that Hyper v1 has been supported for a few versions and that it works fine, it seems like a good time to consider retiring v0. Currently, only adding v1 is possible without forking, thus doubling the hyper stack's dependencies instead of replacing them, since v0 is always enabled even though unused.
Would it therefore be possible to either remove v0 or at least make it optional? Making the
v0
module get behindcfg(not(feature = "hyper1"))
seems to work. The idea would be to have the full re-export kept for both modules so that only the Cargo feature controls what is selected and passing from one to the other would be a drop-in, at least from the item paths point of view. Not pulling any v0 when v1 is enabled and vice-versa would be a priority.I've made an attempt at this in #304.
Thanks in advance,
Paul.
The text was updated successfully, but these errors were encountered: