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

[Ian Lynagh]

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

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:
>     http://search.cpan.org/~jpeacock/version-0.74/lib/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)
    1
      DB<2> p version->new(0.2.0) > version->new(0.1)
    
      DB<3> p version->new(0.2)->normal
    v0.200.0
      DB<4> p version->new(0.2.0)->normal
    v0.2.0
      DB<5> 

> [...]

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
    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.


Thanks
Ian