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