Malcolm Wallace wrote:

...

...

Proposal: that values of the type Data.Version.Version should compare equal, by ignoring trailing zeros. Thus 1.2.0 == 1.2, rather than 1.2.0 > 1.2

Simon Marlow wrote:

...

I see advantages and disadvantages. Advantages: * matches intuitive understanding of versions * lets us drop trailing zeroes in version numbers

maybe, but the trailing zeroes have some effect so far...

...

Disadvantages: * version ordering is slightly harder to explain

Pretty much, yes. Although arguably the disadvantage is not so bad, since currently one has to explain why 1.2.0 is _not_ the same as 1.2.

* it means (==) is not extensional equality for Versions (e.g. (vA == vB && not (show vA == show vB))... then again, this is already true if versionTags is used for anything. (show version), and especially the appending-the-date, depend on how many trailing zeroes are in a particular version so it is likely to be ill-defined, if versions are used as Map keys, which one is stored as the key... not too bad, but people tend to think of (==) as extensional equality most of the time, I think

...

Is there a precedent anywhere else for doing this?

okay, the precedent you demonstrated seems like an advantage if we do this, we should find a way not to depend on the number of trailing zeroes for anything? note that, version-wise, unless we imagine (rightly enough) that negative version numbers are forbidden, this would make Version not even obey the Ord laws; currently Prelude Data.Version> Version [1] [] < Version [1,-1] [] True Prelude Data.Version> Version [1,-1] [] < Version [1,0] [] True Prelude Data.Version> Version [1] [] < Version [1,0] [] True #by transitivity; but the proposal would defeat that Actually not if [1,-1] < [1], which would be plausible to be part of the implicit trailing zeroes concept Isaac

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