Perhaps they want a newer one (bug fix, security fix).
Perhaps they want an older one (since another dependency was tested against an older version of the dep in question).
Semver gives you a way to decide what ranges of versions should be safe to move between in order to satisfy all of those occasionally conflicting requirements.
Explicitly limiting your consumers to a specific version of another library is a breaking change. You have introduced a very specific dependency and are requiring the consumer to honour it.
By semvar rules you should be updating the major version?
If my library requires X version 1.2 or higher, how is it a breaking change if I don't work with version 2.0 or 1.0 or anything except 1.2 through 1.99999?
That's the whole point of software versioning, no matter what you call it (renaming things, semver, git hashes, anything). At some point you require something of someone else, and you can only use the versions of that other library which provide what you require (or more). Semver is just a way to lock those requirements into a machine-readable number scheme.
That limitation is healthy. If versions 1.1 and 1.2 of a class exist and I'm foolish and determined enough to use both in the same process (via multiple classloaders), Java will still ensure that I can't accidentally give a 1.1 instance to a callee expecting a 1.2 instance, or vice versa. Version mismatches at call sites fail quickly and loudly with classloading exceptions.
I think a hell of a lot of NPM packages only appear to work by accident, and over time they'll fail because of sloppiness about this.
Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies.
It doesn't work this way in Java world due to technical limitations, but it can in JS world