It's not good to specify open version ranges in cabal build-depends like foo >= 1.1 because the foo maintainer will eventually release 2.0, containing API-breaking changes, and the build will fail. If you depend on foo 1.1, you can specify == 1.*, no problem. But if you depend on a package that uses a version scheme like 1.2.3 or 1.2.3.4, it's not clear (at least to me) where the major/minor division is. I did a survey of version schemes in 'cabal list': 484 packages use a.b. 630 packages use a.b.c. 180 packages use a.b.c.d. The rest: two packages use just one field for their versions; one uses five; one uses six. Maybe most of the a.b people are thinking major.minor, and most of the a.b.c people are thinking breaking.feature.implementation like the "rational" RubyGems scheme described in http://rubygems.org/read/chapter/7#page24 , but I don't know. It makes it hard to describe dependencies. Will there be a standard versioning scheme sometime?