SemVer and peer dependecies


elm/http was upgraded to 2.0 yesterday.

Packages that use this e.g. dillonkearns/elm-graphql can upgrade their dependency and then publish a minor version.

But if I try to upgrade elm-graphql all my code that uses Http won’t work. I’m forced to upgrade elm/http as well and change my code

My understanding of a minor version if that I should be able to bump that library without touching any of my code, which is not true here.

I’m not an expert on semver but this seems off.
Shouldn’t upgrading a major version in a peer dependency require a major version bump in a library?


Disclaimer: not a semvar expert either!

I think it would be a PATCH version. dillonkearns/elm-graphql had a minor version bump because a new function was added.

You need to consider the most significant version. You upgraded the minor version of dillonkearns/elm-graphql, but also the major version of elm/http, so your existing code might have to be updated.

If you did not have a direct dependency on elm/http, you should be able to upgrade minor or patch versions dillonkearns/elm-graphql without affecting your code.


In general this isn’t true in Elm; a MINOR bump means the package exposes new values, which could possibly lead compilation to fail on an ambiguous name which was unambiguous before the addition.

I don’t think there is any universally accepted definition of exactly what semver should mean; Elm’s definition is defined only in terms of public API:

  • PATCH = public API is identical to previous one
  • MINOR = public API has additions
  • MAJOR = public API has removals or changes


After thinking it over, I realized that there is another benefit to the current approach. If a major version bump was forced when a library’s peers had a major version bump, then you would lose some information. Right now, you get a complete picture of which APIs have breaking changes by looking at the version number change for the package itself and its dependencies. Perhaps there’s some opportunity to present which peers constraints had major changes in the package docs or with feedback from the CLI.

Either way, I’m glad you brought this topic up @Sebastian, it’s good to make this more clear and explicit, and having this here for reference might help someone avoid confusion in the future.


I think the main issue is not the definition of semantic versioning, but enforcing the same dependency version for different packages. If the dependency is not exposing parts of the conflicting transitive dependency, it might be reasonable to support different direct and indirect versions in general. This is a complicated topic.


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.