Simon Marlow wrote (snipped):

I like the idea of representing a version as [Int], using lexicographic ordering; like CVS versions, this lets you branch the tree as much as you like by adding an extra component.

However, this presents a small problem for GHC versions, where eg. 6.2.2004025 is supposed to be earlier than 6.2.1. So perhaps we should elaborate the type:

type Branch = [Int] data Version = Release Branch | Snapshot Branch ClockTime

This seems to me far too dependent on GHC. I suggest that abstract or not, each Version value contains the following information: The format of "tags" should be entirely up to the vendor branch :: [Int] date :: ClockTime tags :: [String] Other information should be included as well of course, but is not relevant to this discussion. Information about whether something is (in GHC-speak) a "release" or a "snapshot" should properly be in (tags). But other people should not be obliged to use the GHC distinction between "release" and "snapshot". There are two natural orderings, namely by branch and by clocktime, but there's not really a lot you can do about that. It is entirely plausible version 6.2.2 of something should have a release date after 6.4. (If, for example, a number of Luddites have still to convert to 6.4, but need a bug fixed.) My vote would be for making Ord compare date first (since that is a linear value), then branch, and then tags, but I can see that other people may have different equally valid opinions. In any case there's not a whole lot of point arguing about it. The fact that GHC refers to a snapshot of 6.2 on 13th April 2004 as "6.2.20040413" is a vile hack which this discussion should certainly ignore!