[Haskell-cafe] hackage version scheme survey

[brian at lorf.org]

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?