proposal: in base, for Data.Version,
change the meaning of comparisons
igloo at earth.li
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 gmail.com> 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
More information about the Libraries