Compiler Versions

George Russell ger at
Tue Apr 13 14:28:55 EDT 2004

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

More information about the Libraries mailing list