Skip to content

Use more conservative net-http version constraint#53

Merged
iMacTia merged 1 commit into
lostisland:mainfrom
RDeckard:feat/stricter-net-http-constraint
Nov 7, 2025
Merged

Use more conservative net-http version constraint#53
iMacTia merged 1 commit into
lostisland:mainfrom
RDeckard:feat/stricter-net-http-constraint

Conversation

@RDeckard

@RDeckard RDeckard commented Nov 7, 2025

Copy link
Copy Markdown
Contributor

Summary

Changes the net-http dependency constraint from >= 0.5.0 to ~> 0.5 to provide better protection against breaking changes in future major versions.

Motivation

The current constraint >= 0.5.0 is very permissive, as it allows any version upgrade, including major version bumps (1.0.0, 2.0.0, etc.) which could introduce breaking changes.

The new constraint ~> 0.5 provides better protection while maintaining flexibility:

  • ✅ Allows all 0.x versions (0.5.x, 0.6.x, 0.7.x, etc.), giving downstream projects flexibility
  • ✅ Blocks automatic upgrades to 1.0+ major versions, where breaking changes are expected
  • ✅ Makes major version bumps more explicit in dependency update PRs

Changes

- spec.add_runtime_dependency 'net-http', '>= 0.5.0'
+ spec.add_runtime_dependency 'net-http', '~> 0.5'

⚠️ Additional important context ⚠️

This change was prompted by a recent incident with https://github.com/ruby/net-http/releases/tag/v0.7.0, which introduced a breaking change (removal of automatic Content-Type: application/x-www-form-urlencoded header for requests with a body) but was released as a minor version bump. Because of the permissive >= 0.5.0 constraint in faraday-net_http, projects using it as a transitive dependency were automatically upgraded to this 0.7.0 version of net-http during unrelated dependency updates, causing unexpected production issues.1

Further improvements

While ~> 0.5 still allows 0.7.x (since it permits all 0.x versions), it provides protection against future major versions. If you'd prefer even stricter protection, we could consider ~> 0.6 instead, which would block 0.7+ entirely. However, this might be too restrictive for projects that have already upgraded to net-http 0.7.

WDYT?

Footnotes

  1. Of course, the reviewer is ultimately responsible for checking all changes in the PR, including transitive dependencies. That said, bumping minor versions when introducing breaking changes makes it more likely such updates go unnoticed, raising the risk of unexpected production issues that are then particularly difficult to trace.

Changes the net-http dependency from `>= 0.5.0` to `~> 0.5`.

The previous constraint (`>= 0.5.0`) allowed any version upgrade,
including major version bumps (e.g., 1.0.0, 2.0.0) which could
introduce breaking changes.

The new constraint `~> 0.5` allows flexibility across 0.x versions
(0.5.x, 0.6.x, 0.7.x, etc.) while protecting against automatic upgrades
to 1.0+ major versions. This provides a better balance between:
- Flexibility for projects to choose their preferred 0.x version
- Protection against major breaking changes in future releases

This change helps prevent unexpected breaking changes from being
automatically pulled into projects relying on faraday-net_http
as a transitive dependency.

@iMacTia iMacTia left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This makes sense, thank you!

@iMacTia iMacTia merged commit 9c90d68 into lostisland:main Nov 7, 2025
@wlipa

wlipa commented Nov 10, 2025

Copy link
Copy Markdown

Some of the ruby core team feel that this kind of conservative gem versioning is a bad idea; see comments in:

https://bugs.ruby-lang.org/issues/21657

@nevans

nevans commented Nov 14, 2025

Copy link
Copy Markdown

In this particular case, not only would the ~> versioning not have prevented the breakage, but net-http doesn't use semver. For net-http's annual x.y release cycle, we also shouldn't expect v1.0 to include any more (or fewer) breaking changes than v0.8 or v0.9. IMO, there's really not much point to using ~> x.y with libraries that don't even claim to use semver. (And technically, even semver allows breaking changes for any 0.x release.)

IMO, the best approach in this case would be to petition net-http for a backwards compatible deprecation period, which I believe they are already leaning toward. (Notice that ruby/net-http#205 has been reopened.)

Tangentially, dependabot upgrading transitive dependencies without also collecting and reporting their release notes (changelog, commits, etc) is one of my biggest annoyances with it (that and the bug where it insists on converting emojis into shortcodes). I consider it a bug. I've seen dependabot upgrade rails as a transitive dependency for some development gem, without a word in the PR description.

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