Compiler versions

[Simon Marlow]

David Roundy writes:
> With the scheme of a triple of Ints, you could have problems 
> with versions
> like 6.2.1pre1 or 6.2.1rc1 which can't easily be mapped to a triple of
> Ints.
> 
> I prefer George's idea of an abstract version type which is 
> an instance of
> Show, Read and Ord.  I'd probably also add majorVersion and 
> minorVersion
> functions, which could return perhaps the same abstract type. 
>  This could
> also be extended to allow the versions of CVS checkouts to be dealt
> with--they could have version numbers like 6.2.1cvs20040402 
> or something.
> Most importantly, though, you wouldn't be defining a version numbering
> policy in the interface.

Using an abstract version type seems to be the best choice for the
reasons you give.  However, there's a compromise here:

  - If you have an abstract version type for the version of
    entity X, then you need one version type for each X, because
    they have different versioning policies.  (e.g. we can't
    use the same version type for the version of the Haskell language
    and the version of the compiler, or versions of libraries).

  - The alternative is to impose a policy.

Perhaps the best choice is to pick a policy that is as unrestrictive as
possible.  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

I'm aware that Hugs versions don't fit well with this type, but there
has been some discussion recently about changing the Hugs versioning
scheme.  The Haskell language versions just about fit into this type (98
> 1.3).

One possible extension is to allow branches to be named, as long as
there was an appropriate way to determine ordering (e.g. an Int
associated with each branch name behind the scenes).

Cheers,
	Simon