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

Update reqwest to latest version ^0.12 #490

Closed
wants to merge 3 commits into from

Conversation

jpopesculian
Copy link

No description provided.

@@ -20,10 +20,14 @@ serde_json = "1.0"

# Optional dependencies
graphql_query_derive = { path = "../graphql_query_derive", version = "0.14.0", optional = true }
reqwest-crate = { package = "reqwest", version = "^0.11", features = ["json"], default-features = false, optional = true }
reqwest11-crate = { package = "reqwest", version = "^0.11", features = ["json"], default-features = false, optional = true }
reqwest-crate = { package = "reqwest", version = "^0.12", features = ["json"], default-features = false, optional = true }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should only have versioned feature flags — since the reqwest upgrade is a breaking change, updating it in the feature flag is a breaking change. I think it's fine because this crate is not 1.0, but we should start prefixing everything. So if that's ok, we could have reqwest11 and reqwest12 features for future proofing.

@jpopesculian jpopesculian requested a review from tomhoule July 10, 2024 14:50
@gusinacio

This comment was marked as off-topic.

Copy link
Contributor

@caspermeijn caspermeijn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that no code is changed for this version bump, would it be possible to support both versions with a version range?

reqwest = { version = ">=0.11, <=0.12", features = ["json", "blocking"] }

I could provide a PR for a CI job that builds the minimal dependency versions if that is appreciated.

@tomhoule
Copy link
Member

reqwest = { version = ">=0.11, <=0.12", features = ["json", "blocking"] }

Not possible, below 1.0, the second component of the version is a major version.

@tomhoule
Copy link
Member

CI is not running, will have to figure that out first.

@tomhoule
Copy link
Member

I don't know why the errors aren't showing up on the PR page, but it looks like clippy isn't passing.

@caspermeijn
Copy link
Contributor

reqwest = { version = ">=0.11, <=0.12", features = ["json", "blocking"] }

Not possible, below 1.0, the second component of the version is a major version.

Why is that not possible? I do something similar in prost:
https://github.com/tokio-rs/prost/blob/0c79864443621f20d92f9acc78a6ab0e7821dab0/prost-build/Cargo.toml#L20

As I understand, cargo update will choose the higher major version, but cargo build allows the lower major version in Cargo.lock. To me, that seems the best of both worlds. You remain compatible with old codebases and support the new dependency version, without the user having to specify which feature to use.

@tomhoule
Copy link
Member

Hmm interesting, that's new to me. We would need to test with all these versions to check for build failiures, but if that works, that may be a solution. I still think the approach in this PR is more straightforward.

@caspermeijn
Copy link
Contributor

CI is not running, will have to figure that out first.

I think running CI jobs requires approval of a maintainer for this repo. https://docs.github.com/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

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.

4 participants