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