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

[Malcolm Wallace]

> > 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 <simonmarhaskell at gmail.com> wrote:

> I see advantages and disadvantages.
> Advantages:
>   * matches intuitive understanding of versions
>   * lets us drop trailing zeroes in version numbers
> 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.

> 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

Perl has a related notion of implicit zero-extension in the "version" pod:
    http://search.cpan.org/~jpeacock/version-0.74/lib/version.pod

Microsoft's .NET Framework seems to ignore trailing zeros in versions:
    http://www.cyscape.com/products/bhawk/docs/BrowserHawk/CompareVersions_Method_NET_.htm
    http://msdn2.microsoft.com/en-us/library/d5cd9b2c.aspx

wxWidgets release numbers sometimes omit trailing zeros:
    http://www.wxwidgets.org/manuals/stable/wx_backwardcompatibility.html

I found proposals to ignore trailing zeros in version comparisons
within OpenOffice, Python distutils, and Drupal:
    http://extensions.openoffice.org/servlets/ReadMsg?list=dev&msgNo=212
    http://mail.python.org/pipermail/distutils-sig/2007-September/008324.html
    http://vbdrupal.org/forum/showthread.php?p=591

> Wouldn't the implementation be simpler if you added a
> dropTrailingZeros  function, and just applied it before comparing? 

Yes, that is another possible implementation.  It involves traversing
both version structures twice rather than once (but I don't suppose the
slight efficiency loss would ever be noticable).

Regards,
    Malcolm