At our startup we actually use Haskell for all our backend code and we've had a lot of package dependency problems. This was all due to people ignoring the versioning policy.
A package that is a bit outdated is far less worse than a package that refuses to compile, because someone felt the need to ignore the versioning policy.
Couldn't the package system adopt a policy like 'foo>=1.2 means any version 1.x where x>=2, foo>=1.2.1 means any version 1.x.y where x>2 or x=2 and y>=1, foo>=0.3.5 means any version 0.3.x where x>=5', etc? This would, at least, mean that bugfix-only updates wouldn't require everyone to bump their packages...
Also, isn't Haskell very statically typed? To the point that you could just assume that, if a package is compatible with foo>=1.2 and compiles against some foo with a higher version number (and passes the test suite, if any), it's also compatible with this new foo? That's mostly how the rest of the world does it, and it works.
That is exactly how it works. The version has four components: A.B.C.D. The first two, A.B, are the major version, and have to be bumped on incompatible changes. The third is a minor version, and has to be bumped if you add to the API. The fourth is free for you to do with as you please.
You can then depend on A.B.* in your package, meaning you get all bugfixes, but no API changes that would break your code.
And statically typed doesn't mean new versions automatically work. If you specify >= 1.2 because you tested with 1.2, and version 1.3 comes out, which doesn't work, people trying to build your package will automatically pull in 1.3, and their build will fail. Specifying 1.2.* means their builds will continue to succeed.
A package that is a bit outdated is far less worse than a package that refuses to compile, because someone felt the need to ignore the versioning policy.