proposal: in base, for Data.Version, change the meaning of comparisons

Ian Lynagh igloo at
Fri Oct 26 20:59:59 EDT 2007

On Fri, Oct 26, 2007 at 11:46:34AM +0100, Malcolm Wallace wrote:
> Simon Marlow <simonmarhaskell at> wrote:
> > Is there a precedent anywhere else for doing this?
> I could point to ordinary decimal notation, where 1.2000 == 1.2.

Well, I don't think anyone is arguing that Cabal should think that
1.2000 == 1.2.

> Perl has a related notion of implicit zero-extension in the "version" pod:

I haven't read the documentation properly to know exactly what the logic
is behind this definition of versions (is it trying to DTRT for
historical perl version numbers?), but it looks pretty scary:

    $ perl -Mversion -de 1
      DB<1> p version->new(0.2) > version->new(0.1)
      DB<2> p version->new(0.2.0) > version->new(0.1)
      DB<3> p version->new(0.2)->normal
      DB<4> p version->new(0.2.0)->normal

> [...]

I don't think software release numbers are very compelling examples,
unless they release both x and x.0 (in which case they presumably are
not going to be considered equal).

For what it's worth, dpkg thinks x.0 > x:

    $ dpkg --compare-versions 1.0 gt 1 && echo yes

I believe rpm does too, although I can't find an easy way to ask it or a
reliable description of what the algorithm does. I also can't
immediately find any details on what Gentoo, *BSD, etc think.

Personally I don't have strong feelings either way, although I lean
slightly towards the current definition. I'd like x.0 to be the same as
x, but Cabal's snapshot version feature (append .$date to the version
number) can tell them apart. Also, I believe the code is simpler for the
current definition.


More information about the Libraries mailing list