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

On Fri, Oct 26, 2007 at 11:46:34AM +0100, Malcolm Wallace wrote:

Simon Marlow 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