Say you've got a package webbrowser, which depends on libhttp

The Haskell package versioning policy < http://www.haskell.org/haskellwiki/Package_versioning_policy > says that your package metadata should specify a minimum and maximum bound on which version of libhttp you support; this way, if a new version of libhttp is released that is backwards-incompatible, they can bump the version and every dependent package will still build correctly.

Say the author of libhttp realizes he really needs to add another parameter to a function. That might break dependents, so it's backwards-incompatible. So he bumps the version from 2.3 to 2.4.

Like a good package author, your browser's dependencies look like this:

    name: webbrowser
    version: 1.0

    build-depends:
      libhttp >= 2.3 && < 2.4

Now you can be notified of the change via < http://packdeps.haskellers.com/ >, download his new package, test it, and verify it works. You didn't use that function, so the change doesn't apply to you. You can change your metadata to:

    build-depends:
      libhttp >= 2.3 && < 2.5

Except now there's a problem. Hackage doesn't support modifying already-uploaded packages; there's no way you can say "webbrowser-1.0 supports 2.3 and 2.4", because it already has a record for webbrowser-1.0. So you have to bump your version:

    version: 1.0.0.1

And re-upload.

And your choice is 1) do this for every package and every dependency, or 2) ignore the versioning policy, hope no dependency changes break your packages.

It sucks.

The general feeling I get from core Haskell developers is that they work in finance, medical, or other fields where every dependency has to undergo a four-month certification process before it can be used. So they don't care about this, because they just never see it.

But for somebody who just wants to publish his stuff online and let others use it, it's a goddamn nightmare.

The other day, the developer of the 'text' package bumped his version to 0.11. As far as I can tell, it doesn't actually have any significant changes. All he did was fix an obscure edge condition when a particular function is passed invalid input. Everything that could build against 0.10, will build against 0.11.

Since I followed the package versioning policy, most of my packages < http://packdeps.haskellers.com/feed/?needle=John+Millikin > are set to refuse his new version. It's not too bad now, but sooner or later a user will upgrade their 'text' and then try to install one of my packages and then they will email me asking me why I am so mean and restrictive.

Which means sometime in the next week or to, I need to sit down for a few hours and recompile all my stuff, then bump the versions, then commit and tag and sign and push and sdist and upload. And somewhere in that hour I'm going to be thinking about just removing the bounds check, and letting my users deal with whatever hell befalls them if in three years there is a real breaking change somewhere.

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.

Just pointing out: there was a breaking change from text 0.10.x -> 0.11; a few functions were renamed for consistency with the rest of the Haskell Platform, which it is now part of.

Haskell being functional, that design decision makes some sense ;)