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:
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.